[Apache/Tomcat] 다중 도메인 구성을 위한 VirtualHost 및 AJP 포트 매핑 가이드

하나의 물리 서버에서 여러 도메인(예: aaa.com, bbb.com)을 서비스하기 위해 Apache의 VirtualHost와 Tomcat의 멀티 Service 구성을 연동하는 방법을 정리합니다. 도메인별로 다른 AJP 포트를 할당하여 요청을 분리하는 것이 핵심입니다.

1. 아키텍처 및 원리 (Context)

설정의 목표는 요청 흐름을 다음과 같이 분리하는 것입니다.

• AAA.test.com (Apache:80) → Worker(aaa) → Tomcat AJP(8009) → Service A
• BBB.test.com (Apache:80) → Worker(bbb) → Tomcat AJP(8010) → Service B
• CCC.test.com (Apache:80) → Worker(ccc) → Tomcat AJP(8011) → Service C

---

2. Apache 설정 (httpd-vhosts.conf)

가장 먼저 Apache가 들어오는 도메인(ServerName)을 구분하여 적절한 mod_jk 워커에게 토스하도록 설정합니다.

설정 활성화 (httpd.conf)

# 주석 해제하여 vhosts 설정 파일 로드
Include conf/extra/httpd-vhosts.conf

가상 호스트 정의 (httpd-vhosts.conf)

각 도메인별로 VirtualHost 블록을 생성하고 JkMount를 통해 서로 다른 워커 이름을 지정합니다.

# 1. AAA 도메인 설정
<VirtualHost *:80>
    ServerName AAA.test.com
    DocumentRoot "/WAS/apps/test1"
    
    ErrorLog "logs/aaa-error_log"
    CustomLog "logs/aaa-access_log" common
    
    # 워커 'aaa'에게 모든 요청 전달
    JkMount /* aaa
</VirtualHost>

# 2. BBB 도메인 설정
<VirtualHost *:80>
    ServerName BBB.test.com
    DocumentRoot "/WAS/apps/test2"
    
    ErrorLog "logs/bbb-error_log"
    CustomLog "logs/bbb-access_log" common
    
    # 워커 'bbb'에게 모든 요청 전달
    JkMount /* bbb
</VirtualHost>

# 3. CCC 도메인 설정
<VirtualHost *:80>
    ServerName CCC.test.com
    DocumentRoot "/WAS/apps/test3"
    
    ErrorLog "logs/ccc-error_log"
    CustomLog "logs/ccc-access_log" common
    
    # 워커 'ccc'에게 모든 요청 전달
    JkMount /* ccc
</VirtualHost>

---

3. mod_jk 워커 설정 (workers.properties)

Apache에서 지정한 워커 이름(aaa, bbb, ccc)이 실제로 통신할 Tomcat의 AJP 포트를 정의합니다.

# 워커 리스트 정의
worker.list=aaa,bbb,ccc

# [aaa] 워커 정의 (기본 포트 8009)
worker.aaa.port=8009
worker.aaa.host=localhost
worker.aaa.type=ajp13

# [bbb] 워커 정의 (포트 8010)
worker.bbb.port=8010
worker.bbb.host=localhost
worker.bbb.type=ajp13

# [ccc] 워커 정의 (포트 8011)
worker.ccc.port=8011
worker.ccc.host=localhost
worker.ccc.type=ajp13

---

4. Tomcat 설정 (server.xml)

Tomcat 하나에서 여러 포트를 리슨하기 위해 <Service> 태그를 복제하여 구성합니다. 각 서비스마다 포트(HTTP, HTTPS, AJP)가 겹치지 않도록 주의해야 합니다.

서비스 A (AAA) 설정

<Service name="CatalinaA">
    <!-- HTTP Port: 8080 -->
    <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
    
    <!-- AJP Port: 8009 (workers.properties의 aaa와 매핑) -->
    <Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />

    <Engine name="CatalinaA" defaultHost="localhost">
        <Host name="localhost" appBase="/WAS/apps/aaa" unpackWARs="true" autoDeploy="true">
            <Context path="" docBase="." reloadable="true"/>
        </Host>
    </Engine>
</Service>

서비스 B (BBB) 설정

<Service name="CatalinaB">
    <!-- HTTP Port: 8081 (충돌 방지) -->
    <Connector port="8081" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8444" />
    
    <!-- AJP Port: 8010 (workers.properties의 bbb와 매핑) -->
    <Connector port="8010" protocol="AJP/1.3" redirectPort="8443" />

    <Engine name="CatalinaB" defaultHost="localhost">
        <Host name="localhost" appBase="/WAS/apps/bbb" unpackWARs="true" autoDeploy="true">
            <Context path="" docBase="." reloadable="true"/>
        </Host>
    </Engine>
</Service>

서비스 C (CCC) 설정

<Service name="CatalinaC">
    <!-- HTTP Port: 8082 (충돌 방지) -->
    <Connector port="8082" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8445" />
    
    <!-- AJP Port: 8011 (workers.properties의 ccc와 매핑) -->
    <Connector port="8011" protocol="AJP/1.3" redirectPort="8443" />

    <Engine name="CatalinaC" defaultHost="localhost">
        <Host name="localhost" appBase="/WAS/apps/ccc" unpackWARs="true" autoDeploy="true">
            <Context path="" docBase="." reloadable="true"/>
        </Host>
    </Engine>
</Service>

Tip (docBase 설정):
appBase와 Context docBase 설정이 꼬일 경우 404 에러가 발생할 수 있습니다. 가장 확실한 방법은 docBase에 절대 경로를 명시하는 것입니다.
예: docBase="/WAS/apps/ccc"

---

5. 검증 및 테스트

1. Tomcat 재기동: server.xml 수정 후 재기동.

   netstat -anotp | grep java 
   # 8009, 8010, 8011 포트가 모두 LISTEN 상태인지 확인

2. Apache 재기동: 설정 적용.

   ./apachectl restart

3. 브라우저 접속: 각 도메인으로 접속하여 서로 다른 페이지가 뜨는지 확인합니다.

[그림] 도메인별 연동 테스트 결과 화면

[Apache/Tomcat] 웹 서버 연동 가이드: mod_jk (AJP) 설정 완벽 정리

Apache HTTP Server와 Tomcat을 연동(Interlink)하여 정적 컨텐츠 처리 성능을 높이고 부하 분산(Load Balancing) 환경을 구성합니다. 가장 널리 사용되는 mod_jk 모듈의 설치(컴파일)부터 workers.properties 설정까지의 전체 과정을 다룹니다.

0. 기본 개념 (Concepts)

• mod_jk: Apache가 Tomcat과 통신하기 위해 사용하는 플러그인 모듈입니다.
• AJP (Apache JServ Protocol): 웹 서버와 WAS 간의 효율적인 통신을 위해 최적화된 바이너리 프로토콜입니다. (Tomcat 기본 AJP 포트: 8009)

---

1. mod_jk 설치 (Compile)

mod_jk는 Apache 배포판에 기본 포함되어 있지 않으므로, 소스를 다운로드하여 컴파일해야 합니다. 이 과정에서 Apache의 확장 도구인 apxs가 필요합니다.

다운로드 및 압축 해제

최신 버전은 Tomcat Connectors 다운로드 페이지에서 확인 가능합니다.

# 1. 소스 다운로드 (버전은 시점에 따라 다를 수 있음)
wget http://apache.mirror.cdnetworks.com/tomcat/tomcat-connectors/jk/tomcat-connectors-1.2.41-src.tar.gz

# 2. 압축 해제
tar -zxvf tomcat-connectors-1.2.41-src.tar.gz

Configure 및 컴파일

native 디렉토리로 이동하여 컴파일을 수행합니다. 주의: --with-apxs 옵션에는 현재 설치된 Apache의 apxs 바이너리 절대 경로를 정확히 입력해야 합니다.

cd tomcat-connectors-1.2.41-src/native

# Apache 설치 경로에 맞춰 apxs 경로 지정 (/WAS/apache/bin/apxs)
./configure --with-apxs=/WAS/apache/bin/apxs

# 컴파일 및 설치
make && make install

설치 확인 (Verification)

설치가 완료되면 Apache의 modules 디렉토리에 mod_jk.so 파일이 생성되었는지 확인합니다.

ls -l /WAS/apache/modules/mod_jk.so

---

2. 워커 설정 (workers.properties)

Apache에게 "어떤 Tomcat 인스턴스와 통신할지" 알려주는 설정 파일입니다. 일반적으로 conf 디렉토리에 생성합니다.

파일 생성

vi /WAS/apache/conf/workers.properties

설정 내용 작성

# Tomcat 및 Java 경로 (환경에 맞게 수정)
workers.tomcat_home="/WAS/tomcat8"
workers.java_home="/usr/bin/java"
ps=/

# 워커 목록 정의 (콤마로 구분하여 다수 정의 가능)
worker.list=test1

# [test1] 워커 상세 설정
worker.test1.port=8009
worker.test1.host=localhost
worker.test1.type=ajp13
# worker.test1.lbfactor=1 (로드밸런싱 시 사용)

Note: worker.test1.port는 Tomcat의 server.xml 내 <Connector protocol="AJP/1.3" ... /> 에 설정된 포트와 일치해야 합니다. (기본값: 8009)

---

3. Apache 설정 (httpd.conf)

마지막으로 Apache가 mod_jk 모듈을 로드하고, 특정 요청을 Tomcat(워커)으로 보내도록 설정합니다.

파일 수정

vi /WAS/apache/conf/httpd.conf

추가 내용

# 1. mod_jk 모듈 로드
LoadModule jk_module modules/mod_jk.so

<IfModule jk_module>
    # 2. 워커 설정 파일 위치 지정
    JkWorkersFile "conf/workers.properties"

    # 3. 로그 설정 (트러블슈팅을 위해 필수)
    JkLogFile "logs/mod_jk.log"
    JkLogLevel info
    JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
    JkRequestLogFormat "%w %V %T"
    
    # 4. URL 매핑 (JkMount)
    # /* : 모든 요청을 test1 워커(Tomcat)로 전달
    # 특정 확장자만 보내려면: JkMount *.jsp test1
    JkMount /* test1
</IfModule>

---

4. 기동 및 연동 테스트

설정이 완료되면 Apache와 Tomcat을 재기동합니다. 순서는 Tomcat 구동 -> Apache 구동 순서를 권장합니다.

설정 검증 (Syntax Check)

# Apache 설정 문법 검사
/WAS/apache/bin/apachectl -t
# "Syntax OK" 출력 확인

서비스 재기동

# Tomcat 재기동
/WAS/tomcat8/bin/shutdown.sh
/WAS/tomcat8/bin/startup.sh

# Apache 재기동
/WAS/apache/bin/apachectl restart

최종 확인

브라우저에서 Apache 포트(보통 80)로 접속했을 때, Tomcat의 페이지가 보인다면 연동에 성공한 것입니다.

---

Next Step:
연동에 성공했다면 정적 파일(이미지, CSS, JS)은 Apache가 처리하고, 동적 파일(JSP)만 Tomcat이 처리하도록 JkMount와 JkUnMount 설정을 튜닝하여 성능을 최적화해 보세요.

[Tomcat] Linux 환경 Apache Tomcat 8.x 설치 및 구성 가이드 (Java, Firewall 설정 포함)

Apache Tomcat은 전 세계적으로 가장 많이 사용되는 경량 웹 애플리케이션 서버(WAS)입니다. Java 기반의 서블릿 컨테이너이므로 JDK 설치가 선행되어야 합니다. 본 포스팅에서는 Linux(CentOS) 환경에서 Java 설치부터 Tomcat 구동, 그리고 방화벽 설정까지의 전체 과정을 다룹니다.

[Image of Apache Tomcat architecture]

1. 사전 준비: Java (JDK) 설치 확인

Tomcat은 Java로 작성된 애플리케이션이므로 서버에 JDK(Java Development Kit)가 설치되어 있어야 구동됩니다. 단순 JRE보다는 개발 및 디버깅 도구가 포함된 JDK 설치를 권장합니다.

설치 여부 확인

# Java 버전 확인
java -version

# 설치 경로 확인
which java

명령어 실행 시 버전 정보가 출력되지 않는다면 JDK를 설치해야 합니다.

JDK 설치 (yum 사용 시)

Oracle JDK는 라이선스 이슈가 있으므로, 오픈소스인 OpenJDK 설치를 권장합니다.

# OpenJDK 1.8 설치 예시
yum install -y java-1.8.0-openjdk-devel

# 설치 후 환경변수 확인 (필수)
# Tomcat은 JAVA_HOME 변수를 참조하므로 설정되어 있는지 확인합니다.
echo $JAVA_HOME

Note: JAVA_HOME 환경 변수가 설정되어 있지 않다면 /etc/profile 등에 경로를 등록해야 Tomcat이 정상적으로 실행됩니다.

---

2. Tomcat 설치 (Download & Install)

패키지 매니저(yum)로 설치할 수도 있지만, 실무에서는 버전 관리와 디렉토리 구조 커스터마이징을 위해 Binary Core(tar.gz)를 직접 다운로드하여 설치하는 방식을 선호합니다.

다운로드 및 압축 해제

최신 버전은 Apache Tomcat 공식 사이트에서 확인 가능합니다.

# 1. 설치 파일 다운로드 (wget)
# (링크는 버전에 따라 달라질 수 있으니 공식 사이트 참조)
wget http://archive.apache.org/dist/tomcat/tomcat-8/v8.0.27/bin/apache-tomcat-8.0.27.tar.gz

# 2. 압축 해제
tar -zxvf apache-tomcat-8.0.27.tar.gz

# 3. 디렉토리 이동 및 정리 (관리 편의성)
# /WAS 디렉토리 하위로 이동하여 관리하는 것을 가정합니다.
mv apache-tomcat-8.0.27 /WAS/tomcat8

---

3. Tomcat 구동 및 로그 확인

Tomcat의 실행 스크립트는 bin 디렉토리에 위치합니다.

서비스 기동

cd /WAS/tomcat8/bin

# 실행 스크립트
./startup.sh

구동 로그 확인 (중요)

startup.sh를 실행했다고 해서 무조건 성공한 것은 아닙니다. 반드시 로그 파일(catalina.out)을 열어 에러 없이 "Server startup in [xxxx] ms" 메시지가 뜨는지 확인해야 합니다.

# 실시간 로그 확인
tail -f /WAS/tomcat8/logs/catalina.out

---

4. 방화벽 설정 및 접속 테스트

Tomcat이 정상 구동되었더라도 외부에서 접속이 안 된다면 방화벽(Firewall) 문제입니다. Tomcat의 기본 포트는 8080입니다.

포트 리슨 확인

# 8080 포트가 LISTEN 상태인지 확인
netstat -anotp | grep 8080

방화벽 오픈 (CentOS 7 이상)

# 8080 포트 영구 허용
firewall-cmd --permanent --zone=public --add-port=8080/tcp

# 방화벽 설정 재로드
firewall-cmd --reload

최종 접속 확인

브라우저 주소창에 http://[서버IP]:8080 을 입력합니다.

• 성공: Apache Tomcat 고양이 로고가 그려진 기본 페이지가 출력됩니다.
• 실패: "사이트에 연결할 수 없음"이 뜬다면 방화벽 설정이나 클라우드 보안 그룹(Security Group) 설정을 다시 확인하세요.

---

Next Step:
설치가 완료되었다면, 운영 환경에 맞춰 /WAS/tomcat8/conf/server.xml 파일에서 포트(Port)를 80으로 변경하거나, UTF-8 인코딩 설정을 추가하는 튜닝 작업을 진행해 보십시오.

[Apache] Linux 소스 컴파일 설치 가이드 (httpd, apr, pcre)

Linux 환경에서 yum이나 apt 같은 패키지 매니저 대신, Apache HTTP Server(httpd)를 소스 코드로 직접 컴파일하여 설치하는 방법을 정리합니다. 특정 버전이 필요하거나, 모듈을 커스터마이징해야 할 때 필수적인 기술입니다.

0. 시작하기 전에 (Why & Prerequsite)

왜 소스 컴파일을 하나요?

• 버전 관리: OS 저장소(Repository)에서 제공하는 구버전이 아닌, 최신 보안 패치가 적용된 버전을 사용할 수 있습니다.
• 최적화: 불필요한 모듈을 빼거나, 경로를 /usr/local이 아닌 /WAS 등 원하는 곳으로 지정하여 관리 효율성을 높일 수 있습니다.

필수 컴파일 도구 설치

소스 코드를 기계어로 번역하기 위해서는 컴파일러(gcc)와 빌드 도구(make)가 반드시 필요합니다. 설치 전 아래 명령어로 환경을 준비해주세요.

# CentOS/RHEL 기준
yum install -y gcc gcc-c++ make expat-devel

---

1. 소스 파일 다운로드

각 프로젝트의 공식 홈페이지에서 Stable(안정) 버전을 다운로드합니다. 보통 /usr/local/src 나 임시 디렉토리에서 작업합니다.

다운로드 링크

• Apache HTTPD: http://httpd.apache.org/download.cgi
• APR / APR-Util: https://apr.apache.org/download.cgi
• PCRE: http://www.pcre.org/

※ Apache 2.4 버전부터는 APR(Apache Portable Runtime)과 PCRE(정규표현식 라이브러리)가 내장되어 있지 않아 별도 설치가 필수입니다.

---

2. 의존성 라이브러리 설치

Apache 본체를 설치하기 전에 기초가 되는 라이브러리를 먼저 깔아야 합니다. 관리 편의를 위해 모든 경로는 /WAS 하위로 통일하겠습니다.

1) APR (Apache Portable Runtime) 설치

OS(Linux, Windows 등)에 상관없이 Apache가 실행될 수 있도록 도와주는 플랫폼 추상화 라이브러리입니다.

tar -zxvf apr-1.5.2.tar.gz
cd apr-1.5.2

# --prefix 옵션으로 설치 경로 지정
./configure --prefix=/WAS/apr
make && make install

2) APR-Util 설치

APR의 유틸리티 확장판입니다. 반드시 위에서 설치한 APR의 경로를 지정해야 합니다.

tar -zxvf apr-util-1.5.4.tar.gz
cd apr-util-1.5.4

# --with-apr 옵션 중요!
./configure --prefix=/WAS/aprutil --with-apr=/WAS/apr
make && make install

3) PCRE (Perl Compatible Regular Expressions) 설치

Apache의 URL 재작성(Rewrite) 모듈 등에서 사용하는 정규표현식 라이브러리입니다.

tar -zxvf pcre-8.37.tar.gz
cd pcre-8.37

./configure --prefix=/WAS/pcre
make && make install

---

3. Apache HTTP Server 설치

이제 주인공인 Apache를 설치합니다. configure 단계에서 앞서 설치한 라이브러리들의 경로를 연결해주는 것이 핵심입니다.

Configuration 실행

tar -zxvf httpd-2.4.16.tar.gz
cd httpd-2.4.16

# 한 줄씩 옵션을 확인하며 입력하세요.
./configure \
--prefix=/WAS/apache \
--enable-mods-shared=all \
--enable-so \
--enable-rewrite \
--enable-auth-digest \
--with-apr=/WAS/apr \
--with-apr-util=/WAS/aprutil \
--with-pcre=/WAS/pcre

주요 옵션 설명

• --enable-mods-shared=all: 모듈을 동적(Dynamic)으로 컴파일하여, 추후 httpd.conf에서 Load/Unload가 가능하게 합니다.
• --enable-rewrite: URL 주소를 변경하는 Rewrite 기능을 활성화합니다. (실무 필수)

컴파일 및 설치

# 에러 없이 완료되면 실행
make && make install

---

4. 기동 및 검증 (Verification)

설치가 끝났다고 바로 브라우저가 열리는 것은 아닙니다. 프로세스를 띄우고 포트를 확인해야 합니다.

1) 서비스 기동

# Apache 기동 스크립트 실행
/WAS/apache/bin/apachectl start

# 프로세스 확인 (httpd 프로세스가 보여야 함)
ps -ef | grep httpd

2) 포트 리슨 확인

웹 서버의 기본 포트인 80번이 열려있는지 확인합니다.

netstat -anotp | grep :80

3) 방화벽 설정 (중요!)

프로세스가 떴는데 브라우저 접속이 안 된다면 99%는 방화벽 문제입니다. 테스트를 위해 방화벽을 잠시 끄거나 80포트를 열어야 합니다.

# CentOS 7 (firewalld) 포트 오픈 예시
firewall-cmd --permanent --zone=public --add-port=80/tcp
firewall-cmd --reload

4) 최종 접속 테스트

PC 브라우저 주소창에 http://[서버IP]를 입력합니다. 화면에 "It works!"가 보인다면 성공입니다.

---

Next Step:
이제 /WAS/apache/conf/httpd.conf 파일을 열어 ServerName 경고 메시지를 해결하고, DocumentRoot(웹 문서 위치)를 실제 운영 경로로 변경해 보세요.

[Linux] FTP CLI 명령어 완벽 가이드 및 상태 코드(Response Code) 정리

리눅스 쉘 환경에서 FTP 서버에 접속하여 파일을 업로드/다운로드하는 필수 명령어와 주요 옵션을 정리합니다. 또한 트러블슈팅 시 유용한 FTP 응답 코드(Response Code)의 의미를 설명합니다.

[Image of FTP client server data transfer diagram]

1. 서버 접속 및 로그인 (Connection)

FTP 클라이언트를 실행하여 원격 서버에 접속하는 과정입니다. open 명령어를 사용하거나 실행 시 인자로 IP를 전달합니다.

[test@zeroTest]$ ftp 210.xxx.xxx.xxx
Connected to 210.xxx.xxx.xxx.
220 web17 FTP server (Version 5.60) ready.
Name (210.xxx.xxx.xxx:test): [아이디 입력]
331 Password required for user.
Password: [패스워드 입력]
230 User test logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

---

2. 디렉토리 탐색 (Navigation)

FTP는 원격(Remote) 서버와 로컬(Local) 클라이언트의 디렉토리를 동시에 제어해야 합니다. 로컬 명령어 앞에는 주로 l(local)이 붙습니다.

원격 서버 (Remote) 제어

• pwd : 원격 서버의 현재 경로 확인
• ls (또는 dir) : 원격 서버의 파일 목록 출력
• cd [path] : 원격 서버의 디렉토리 이동
• cdup : 원격 서버에서 상위 디렉토리로 이동

로컬 클라이언트 (Local) 제어

• !pwd : 로컬 클라이언트의 현재 경로 확인
• lcd [path] : 로컬 클라이언트의 작업 디렉토리 변경 (다운로드/업로드 위치 변경 시 필수)

# 로컬 다운로드 경로를 /bin으로 변경 예시
ftp> lcd /bin
Local directory now /bin

---

3. 파일 전송 설정 (Transfer Settings)

파일 전송 전, 전송 모드와 시각적 피드백 옵션을 설정하는 것이 중요합니다.

전송 모드 (Transfer Mode)

바이너리 파일(이미지, 실행파일, 압축파일 등) 전송 시 반드시 binary 모드를 사용해야 파일 깨짐을 방지할 수 있습니다.

• ascii (또는 as) : 텍스트 파일 전송 모드
• binary (또는 bi) : 바이너리 전송 모드 (권장)

편의 옵션

• hash : 파일 전송 진행 상황을 #(Hash Mark)로 표시 (대용량 파일 전송 시 유용)
• prompt : 다중 파일 전송(mget/mput) 시 파일마다 확인하는 과정을 On/Off

ftp> binary
200 Type set to I.
ftp> hash
Hash mark printing on (1024 bytes/hash mark).

---

4. 파일 업로드 및 다운로드

단일 파일 처리와 다중 파일(Wildcard * 사용) 처리 명령어가 구분됩니다.

다운로드 (Server -> Local)

• get [filename] : 단일 파일 다운로드
• mget [pattern] : 다중 파일 다운로드 (예: mget *.pdf)

ftp> get thinkinjava.pdf
local: R389.PDF remote: R389.PDF
200 PORT command successful.
150 Opening BINARY mode data connection for R389.PDF (44028 bytes).
#######################
226 Transfer complete.

업로드 (Local -> Server)

• put [filename] : 단일 파일 업로드
• mput [pattern] : 다중 파일 업로드 (예: mput *.html)

---

5. 기타 관리 명령어

• delete [filename] / mdelete [pattern] : 원격 파일 삭제
• mkdir [dirname] / rmdir [dirname] : 원격 디렉토리 생성 및 삭제
• chmod [mode] [file] : 원격 파일 권한 변경 (예: chmod 755 run.sh)
• rename [old] [new] : 파일 이름 변경
• size [filename] : 파일 크기(Byte) 확인
• bye, quit, exit : 접속 종료

---

6. FTP 응답 코드 (Response Codes)

서버가 반환하는 3자리 숫자를 통해 트러블슈팅이 가능합니다. 주요 코드는 다음과 같습니다.

Code	Description (의미)
150	파일 상태 정상. 데이터 연결을 엽니다. (전송 시작)
200	명령어 성공 (OK)
220	서비스 준비 완료 (접속 초기 메시지)
226	데이터 연결 닫힘. 요청 작업 성공 (전송 완료)
230	사용자 로그인 성공
331	사용자 이름 확인됨. 패스워드 필요
421	서비스 사용 불가. 연결 종료
425	데이터 연결을 열 수 없음 (방화벽, Passive 모드 이슈 등)
530	로그인 실패 (ID/PW 오류)
550	요청 작업 실패 (파일 없음, 권한 부족 등)

---

Next Step:
FTP는 데이터를 암호화하지 않아 보안에 취약합니다. OpenSSH에 포함된 sftp 명령어를 사용하여 암호화된 파일 전송 환경을 구성하는 방법을 검토해보십시오.

[WebSphere] JSESSIONID 충돌 해결: 동일 도메인 세션 분리 전략 (Cookie Name 변경)

동일한 도메인(예: www.test.com) 아래에서 컨텍스트 루트(Context Root)만 다른 여러 애플리케이션을 운영할 때, 브라우저가 세션 쿠키(JSESSIONID)를 구분하지 못해 세션이 끊기거나 덮어써지는 현상을 해결하는 방법을 정리합니다.

1. 문제 상황 및 원인 (Context)

WAS는 클라이언트 식별을 위해 JSESSIONID라는 이름의 쿠키를 기본적으로 사용합니다. 하지만 아래와 같은 구성에서는 문제가 발생합니다.

• 서비스 A: http://domain.com/app1 (Server1)
• 서비스 B: http://domain.com/app2 (Server2)

브라우저는 기본적으로 도메인 단위로 쿠키를 관리합니다. 사용자가 '서비스 A'를 이용하다가 '서비스 B'로 이동하면, 브라우저는 기존 '서비스 A'의 JSESSIONID를 '서비스 B'의 새로운 JSESSIONID로 덮어씌웁니다(Overwrite). 다시 '서비스 A'로 돌아가면 세션 ID가 달라졌으므로 로그인이 풀리게 됩니다.

---

2. 해결 방법 1: 서버 레벨 설정 (Server Level)

가장 간단한 방법은 각 서버(인스턴스)마다 쿠키 이름을 다르게 설정하는 것입니다.

설정 경로

서버(Servers) > 서버 유형(Server Types) > WebSphere Application Servers > [서버명] > 세션 관리(Session management) > 쿠키 사용 가능(Enable cookies) 링크 클릭

설정 변경

• 쿠키 이름 (Cookie name): 기본값 JSESSIONID를 식별 가능한 이름으로 변경합니다.
  • Server1: JSESSIONID_SVR1
  • Server2: JSESSIONID_SVR2

Pros/Cons: 설정이 간편하지만, 하나의 서버 안에 여러 애플리케이션이 존재할 경우 그 안에서는 여전히 충돌이 발생할 수 있습니다.

---

3. 해결 방법 2: 애플리케이션 레벨 설정 (App Level)

보다 세밀하게 애플리케이션(WAR/EAR) 단위로 세션을 격리하고 싶을 때 사용합니다. 권장되는 방식입니다.

설정 경로

애플리케이션(Applications) > 엔터프라이즈 애플리케이션(Enterprise Applications) > [애플리케이션명] > 세션 관리(Session management) > 쿠키 사용 가능(Enable cookies) 링크 클릭

설정 변경

1. 세션 관리 대체 (Override session management): 반드시 체크합니다. (상위 서버 설정을 무시하고 이 설정을 따르겠다는 의미)
2. 쿠키 이름 (Cookie name): 해당 앱 전용 쿠키 이름 설정 (예: JSESSIONID_APP1)
3. 쿠키 경로 (Cookie path): 필요시 /app1 처럼 컨텍스트 루트로 한정 지을 수도 있습니다.

---

4. 필수 후속 조치: 플러그인 갱신 (Plugin Propagate)

WAS 설정만 바꾸고 끝내면 안 됩니다. 앞단의 웹 서버(IHS/Apache)가 변경된 쿠키 이름을 인식하여 세션 어피니티(Session Affinity, 스티키 세션)를 유지할 수 있도록 plugin-cfg.xml을 갱신해야 합니다.

작업 절차

1. WAS 관리 콘솔에서 변경 사항 저장.
2. Environment > Update global Web server plug-in configuration (또는 웹 서버 메뉴에서 플러그인 생성/전파).
3. 웹 서버(IHS) 재기동 (Graceful Restart).

확인 (plugin-cfg.xml)

생성된 플러그인 파일을 열어 AffinityCookie 속성이 변경되었는지 확인합니다.

<UriGroup Name="default_host_Cluster_URIs">
    <!-- AffinityCookie 값이 변경된 이름과 일치해야 함 -->
    <Uri AffinityCookie="JSESSIONID_APP1" AffinityURLIdentifier="jsessionid" Name="/*"/>
</UriGroup>

---

5. 검증 (Verification)

설정이 올바르게 적용되었는지 확인하는 방법입니다.

1. 브라우저의 개발자 도구 (F12)를 엽니다.
2. Application 탭 > Cookies 메뉴를 선택합니다.
3. 각 애플리케이션에 접속했을 때, JSESSIONID가 아닌 JSESSIONID_APP1, JSESSIONID_APP2 등으로 서로 다른 이름의 쿠키가 생성되는지 확인합니다.

주의 (Warning):
세션 쿠키 이름을 변경하면 기존에 로그인되어 있던 사용자들의 세션은 모두 무효화됩니다. 따라서 이 작업은 서비스 점검 시간이나 사용자가 적은 시간대에 수행해야 합니다.

[WebSphere] WAS v8.5 Command Line 설치 가이드 (Installation Manager / imcl)

WebSphere Application Server v8.0 부터는 Installation Manager(IM)를 통해서만 설치가 가능합니다. GUI 환경을 사용할 수 없는 서버에서 imcl 명령어를 사용하여 IM, WAS ND, JDK, Fix Pack을 순차적으로 설치하는 절차를 정리합니다.

1. 사전 준비 (Prerequisites)

설치를 진행하기 위해 각 제품의 설치 파일(Repository)이 서버에 준비되어 있어야 합니다.

• Installation Manager: 설치 에이전트
• WAS ND v8.5: 애플리케이션 서버 본체
• IBM SDK Java 7: JDK 1.7 (WAS 8.5 기본은 JDK 1.6)
• Fix Pack: 최신 패치 파일

---

2. Installation Manager 설치

WAS를 설치하기 위한 엔진인 Installation Manager를 먼저 설치합니다.

설치 명령어

• 설치 경로: C:\IBM\InstallationManager\eclipse
• Repository 경로: D:\WASV8.5\agent.installer...\repository.config

:: Installation Manager 설치
C:\IBM\InstallationManager_Setup\imcl.exe install com.ibm.cic.agent ^
 -repositories "D:\WASV8.5\agent.installer.win32.win32.x86_1.6.0.20120831_1216\repository.config" ^
 -installationDirectory "C:\IBM\InstallationManager\eclipse" ^
 -acceptLicense ^
 -showProgress -sP

---

3. WebSphere Application Server (WAS) 설치

Step 1: Package ID 확인

설치할 제품의 정확한 ID를 파악해야 합니다. listAvailablePackages 명령어를 사용합니다.

:: 패키지 ID 조회
cd C:\IBM\InstallationManager\eclipse\tools
imcl.exe listAvailablePackages -repositories "D:\WASV8.5\was\was_img" -features -long

:: 출력 예시: com.ibm.websphere.ND.v85_8.5.0.20120501_1108

Step 2: WAS ND 설치 실행

• 설치 경로: C:\IBM\WAS_85
• 공유 리소스 경로: C:\IBM\IMShared

:: WAS ND 설치
imcl.exe install com.ibm.websphere.ND.v85_8.5.0.20120501_1108 ^
 -repositories "D:\WASV8.5\was\was_img" ^
 -installationDirectory "C:\IBM\WAS_85" ^
 -sharedResourcesDirectory "C:\IBM\IMShared" ^
 -acceptLicense ^
 -properties cic.selector.nl=ko ^
 -showProgress -sP

---

4. JDK 7 설치 (Optional)

WAS 8.5는 기본적으로 JDK 6을 사용하므로, JDK 7이 필요한 경우 별도 설치가 필요합니다.

Step 1: Package ID 확인

:: JDK 패키지 ID 조회
imcl.exe listAvailablePackages -repositories "D:\WASV8.5\jdk7\jdk7" -features -long

:: 출력 예시: com.ibm.websphere.IBMJAVA.v70_7.0.1000.20120424_1539

Step 2: JDK 7 설치 실행

이미 설치된 WAS 경로(C:\IBM\WAS_85)에 추가 설치하는 방식입니다.

:: JDK 7 추가 설치
imcl.exe install com.ibm.websphere.IBMJAVA.v70_7.0.1000.20120424_1539 ^
 -repositories "D:\WASV8.5\jdk7\jdk7" ^
 -installationDirectory "C:\IBM\WAS_85" ^
 -acceptLicense ^
 -showProgress -sP

---

5. Fix Pack 업데이트

설치된 WAS 버전을 최신 Fix Pack으로 업데이트합니다.

Step 1: Package ID 확인

:: Fix Pack ID 조회
imcl.exe listAvailablePackages -repositories "D:\WASV8.5\fix\was" -features -long

:: 출력 예시: com.ibm.websphere.ND.v85_8.5.2.20130327_1831

Step 2: 업데이트 실행

:: Fix Pack 적용
imcl.exe install com.ibm.websphere.ND.v85_8.5.2.20130327_1831 ^
 -repositories "D:\WASV8.5\fix\was" ^
 -installationDirectory "C:\IBM\WAS_85" ^
 -acceptLicense ^
 -showProgress -sP

---

6. 설치 검증 (Verification)

모든 설치가 완료되면 versionInfo 명령어로 설치된 제품과 버전을 확인합니다.

cd C:\IBM\WAS_85\bin
versionInfo.bat

---

Next Step:
설치가 정상적으로 완료되었다면 manageprofiles 명령어를 사용하여 프로파일(Dmgr, AppSrv)을 생성하고 startNode 등으로 프로세스를 기동하십시오.

[WebSphere] WAS V5/V6 to V7 마이그레이션 가이드 (WASPreUpgrade, WASPostUpgrade)

기존 WebSphere Application Server(V5.1.x, V6.x) 환경의 구성을 신규 버전(V7.x)으로 이관하는 마이그레이션 절차를 정리합니다. 구성 백업(WASPreUpgrade)과 복구(WASPostUpgrade), 그리고 WebSphere Virtual Enterprise(XD) 환경의 이관 방법을 포함합니다.

1. 사전 준비 및 프로세스 확인

마이그레이션 도구를 실행하기 전, 원본 서버와 대상 서버의 상태를 확인해야 합니다.

• Source WAS (V5/V6): 구성 정보를 읽어야 하므로 구동 상태 확인 (또는 구성 파일 접근 가능 상태).
• Target WAS (V7): 프로파일을 덮어쓰거나 설정을 변경해야 하므로 정지(Stop) 상태여야 함.

---

2. 구성 백업 (WASPreUpgrade)

구 버전 WAS의 구성 정보를 백업 디렉토리로 추출합니다.

구문 (Syntax)

WASPreUpgrade [백업저장경로] [구버전WAS경로] [-oldProfile 프로파일멍] [-machineChange true|false]

실행 예시

Windows 환경

:: V6.1 Dmgr 프로파일을 C:\mybackup 경로로 백업
C:\IBM\WebSphere70\AppServer\bin\WASPreUpgrade.bat C:\mybackup\v61tov7dmgr01 C:\IBM\WebSphere61\AppServer -oldProfile Dmgr01

Linux/Unix 환경

# Dmgr01 프로파일 백업 (머신 변경 옵션 포함)
cd /app/was/AppServer/bin
./WASPreUpgrade.sh /app/was/backup_config /app/was/WebSphere6/AppServer -oldProfile Dmgr01 -machineChange true

---

3. 구성 복구 (WASPostUpgrade)

백업된 구성 정보를 신규 버전(V7)의 프로파일에 적용합니다. 대용량 구성의 경우 타임아웃이 발생할 수 있으므로 사전 조치가 필요합니다.

사전 조치: SOAP Timeout 설정

복구 시간이 오래 걸릴 경우를 대비해 SOAP 요청 타임아웃을 늘려줍니다.

• 파일 위치: [Target_Profile_Root]/properties/soap.client.props
• 설정 변경: com.ibm.SOAP.requestTimeout=1800 (또는 0으로 설정하여 무제한)

구문 (Syntax)

WASPostUpgrade [백업저장경로] [-profileName 대상프로파일] [-oldProfile 구프로파일] [-includeApps true|false] [-keepDmgrEnabled true|false]

실행 예시

Windows 환경

C:\IBM\WebSphere70\AppServer\bin\WASPostUpgrade.bat C:\mybackup\v61tov7dmgr01 ^
 -profileName v61tov7dmgr01 ^
 -oldProfile Dmgr01 ^
 -replacePorts TRUE ^
 -keepDmgrEnabled TRUE

Linux/Unix 환경

cd /app/was/AppServer/profiles/Dmgr01/bin
./WASPostUpgrade.sh /app/was/backup_config \
 -profileName Dmgr01 \
 -oldProfile Dmgr01 \
 -replacePorts true \
 -backupConfig true \
 -scriptCompatibility true \
 -keepDmgrEnabled true \
 -includeApps true \
 -username wasadmin \
 -password wasadmin

주요 옵션 설명

• -replacePorts true: 구 버전에서 사용하던 포트를 신규 버전에서도 그대로 사용합니다. (포트 충돌 주의)
• -includeApps true: 애플리케이션(EAR/WAR) 파일도 함께 마이그레이션합니다.
• -keepDmgrEnabled true: Dmgr이 마이그레이션 중에도 관리 기능을 유지하도록 설정합니다.

---

4. WebSphere Virtual Enterprise (XD/VE) 마이그레이션

WAS ND(Network Deployment) 위에 VE(Virtual Enterprise) 기능이 설치된 경우, 추가적인 단계가 필요합니다.

Step 1: 프로파일 기능 보강 (Augment)

신규 생성된 V7 프로파일에 VE 기능을 사용할 수 있도록 템플릿을 추가(Augment)합니다.

# manageprofiles 명령어로 xd_augment 템플릿 적용
./manageprofiles.sh -augment \
 -profileName profile01 \
 -templatePath [WAS_INSTALL_ROOT]/profileTemplates/xd_augment/dmgr

Step 2: VE 구성 마이그레이션 (VEUpgrade)

기존 VE 셀의 구성을 신규 V7 VE 셀로 이관합니다.

# VEUpgrade 실행 예시
./VEUpgrade.sh \
 -userid wasadmin \
 -password [PASSWORD] \
 -sourcewashome /app/was/WebSphere6/AppServer \
 -sourceprofilepath /app/was/WebSphere6/AppServer/profiles/Dmgr01 \
 -targetprofilepath /app/was/WebSphere/AppServer/profiles/Dmgr01

---

5. 완료 및 확인

1. 구 버전 중지: 포트 충돌 방지를 위해 Source WAS(V5/V6)를 완전히 중지합니다.
2. 신규 버전 기동: Target WAS(V7)의 Dmgr 및 NodeAgent를 기동합니다.

   [WAS7_HOME]/profiles/Dmgr01/bin/startManager.sh

3. 로그 확인: WASPostUpgrade.log 및 SystemOut.log를 확인하여 에러 여부를 점검합니다.

---

Next Step:
마이그레이션이 완료된 후, JDK 버전 차이(JDK 1.4/5 -> JDK 6)로 인한 애플리케이션 호환성 문제가 없는지 검증하는 테스트 계획을 수립하십시오.

[Windows] CMD 프로세스 및 포트 관리 완전 정복 (tasklist, netstat, taskkill)

Windows CMD 환경에서 실행 중인 프로세스를 조회하고, 특정 포트를 점유 중인 서비스를 식별하며, 문제 발생 시 해당 프로세스를 강제로 종료하는 필수 명령어(tasklist, netstat, taskkill) 사용법을 정리합니다.

1. 프로세스 조회 (tasklist)

현재 시스템에서 실행 중인 프로세스 목록을 확인합니다. 필터(/fi) 옵션을 사용하여 특정 프로세스만 검색할 수 있습니다.

이미지 이름으로 검색

특정 실행 파일명(Image Name)을 기준으로 프로세스를 찾습니다. (예: java.exe)

:: 사용법: tasklist /fi "imagename eq [프로세스명]"
C:\Users> tasklist /fi "imagename eq java.exe"

이미지 이름                    PID 세션 이름              세션#  메모리 사용
========================= ======== ================ =========== ============
java.exe                      1234 Console                    1    150,000 K

---

2. 포트 점유 확인 (netstat)

네트워크 상태를 확인하여 특정 포트를 리슨(LISTEN)하고 있는 프로세스의 PID를 식별합니다.

Listening 포트 및 PID 확인

-ano 옵션을 사용하여 모든 연결, 숫자 형식의 주소, 그리고 소유 프로세스 ID(PID)를 함께 출력합니다.

:: 사용법: netstat -ano | find "[문자열]"
C:\Users> netstat -ano | find "LISTEN"

  프로토콜   로컬 주소              외부 주소               상태            PID
  TCP    0.0.0.0:80             0.0.0.0:0              LISTENING       564
  TCP    0.0.0.0:135            0.0.0.0:0              LISTENING       892

---

3. PID로 프로세스 식별 (Reverse Lookup)

netstat으로 확인한 PID(예: 564)가 실제로 어떤 서비스인지 tasklist를 통해 역추적합니다.

PID로 검색

:: 사용법: tasklist /fi "pid eq [PID]"
C:\Users> tasklist /fi "pid eq 564"

이미지 이름                    PID 세션 이름              세션#  메모리 사용
========================= ======== ================ =========== ============
svchost.exe                    564 Services                   0     11,444 K

---

4. 프로세스 강제 종료 (taskkill)

응답하지 않거나 특정 포트를 점유하여 충돌을 일으키는 프로세스를 종료합니다.

PID를 이용한 강제 종료

/f 옵션은 강제 종료(Force)를 의미하며, /pid 옵션으로 대상을 지정합니다.

:: 사용법: taskkill /f /pid [PID]
C:\Users> taskkill /f /pid 6985

성공: 프로세스(PID 6985)가 종료되었습니다.

이미지 이름을 이용한 강제 종료

동일한 이름의 모든 프로세스를 한 번에 종료할 때 유용합니다.

:: 사용법: taskkill /f /im [이미지이름]
C:\Users> taskkill /f /im notepad.exe

---

5. 도움말 및 옵션 확인

각 명령어의 상세한 필터 옵션이나 사용법이 궁금할 경우 /? 플래그를 사용합니다.

tasklist /?
taskkill /?

---

Next Step:
CMD 명령어보다 더 강력하고 객체 지향적인 관리가 필요하다면, PowerShell의 Get-Process, Stop-Process, Get-NetTCPConnection Cmdlet 사용법을 학습해 보시길 권장합니다.

[WebSphere] WAS v6.1/v7.0 Silent Mode 설치, 업데이트 및 삭제 가이드

GUI 환경을 사용할 수 없는 서버에서 WebSphere Application Server(WAS)와 IBM HTTP Server(IHS)를 Response File을 이용하여 Silent Mode(무인 모드)로 설치, 업데이트, 삭제하는 방법을 정리합니다.

1. 설치 로그 확인 방법 (Log Verification)

Silent Mode는 진행 상황이 화면에 표시되지 않으므로, 반드시 로그 파일을 `tail` 명령어로 모니터링해야 합니다.

로그 경로 및 확인

# 설치 로그 경로
# Linux/AIX: [WAS_Install_Dir]/logs/install/log.txt
# 또는 /tmp/log.txt (초기 실패 시)

tail -f log.txt

주요 상태 코드

• INSTCONFSUCCESS: 설치 및 구성 성공.
• INSTCONFPARTIALSUCCESS: 부분 성공 (경고 포함). 로그 확인 필요.
• INSTCONFFAILED: 설치 실패. 원인 분석 필요.

---

2. WebSphere Application Server (WAS) 설치

Step 1: 이미지 압축 해제

cd /home/wasadmin/was_img
tar -xvf was_image.tar

Step 2: Response File 편집

기본 제공되는 responsefile.nd.txt를 복사하여 환경에 맞게 수정합니다.

# 주요 옵션 설정 (res.nd.txt)

# 1. 라이선스 동의 및 OS 사전 검사
-OPT silentInstallLicenseAcceptance="true"
-OPT disableOSPrereqChecking="true"
-OPT allowNonRootSilentInstall="true"  # root가 아닌 계정으로 설치 시

# 2. 설치 타입 (신규 설치)
-OPT installType="installNew"
-OPT profileType="cell"

# 3. 보안 설정 (설치 후 설정 권장 -> false)
-OPT PROF_enableAdminSecurity="false"
# -OPT PROF_adminUserName=
# -OPT PROF_adminPassword=

# 4. 설치 경로 지정
-OPT installLocation="/home/wasadmin/IBM/WebSphere/AppServer"

Step 3: 설치 실행

./install -silent -options res.nd.txt

Step 4: 설치 검증

# 버전 확인
cd [WAS_HOME]/bin
./versionInfo.sh

# 프로세스 구동 (Dmgr -> Node)
[WAS_HOME]/profiles/Dmgr01/bin/startManager.sh
[WAS_HOME]/profiles/AppSrv01/bin/startNode.sh

---

3. IBM HTTP Server (IHS) 설치

Step 1: Response File 편집

IHS용 Response File을 작성합니다.

# 주요 옵션 설정 (ihs.txt)

-OPT silentInstallLicenseAcceptance="true"
-OPT disableOSPrereqChecking="true"
-OPT installLocation="/home/wasadmin/IBM/HTTPServer"

# 포트 설정 (Non-root 설치 시 1024 이상 포트 사용)
-OPT httpPort="80"
-OPT adminPort="8008"

# Admin 계정 설정 (IHS Admin Console용)
-OPT createAdminAuth="true"
-OPT adminAuthUser="admin"
-OPT adminAuthPassword="password"
-OPT adminAuthPasswordConfirm="password"

# 권한 설정 (User/Group)
-OPT createAdminUserGroup="true"
-OPT setupAdminUser="nobody"
-OPT setupAdminGroup="nobody"

# 플러그인 설치 여부 및 WAS 호스트
-OPT installPlugin="true"
-OPT washostname="localhost"
-OPT webserverDefinition="webserver01"

Step 2: 설치 실행

./install -silent -options ihs.txt

Troubleshooting: admin.conf 권한 문제

설치 후 admin.conf 파일의 User/Group 설정이 매크로 변수(@@...)로 남아있다면 수동으로 수정해야 합니다.

# [IHS_HOME]/conf/admin.conf 수정
User nobody
Group nobody

---

4. Update Installer 및 Fix Pack 적용

WAS 패치(Fix Pack)를 적용하기 위해서는 먼저 Update Installer를 설치해야 합니다.

Step 1: 사전 작업 (프로세스 정지)

업데이트 전 관련된 모든 Java 및 HTTP 프로세스를 중지합니다.

# 프로세스 확인 및 종료
ps -ef | grep java
kill -9 [PID]

Step 2: Update Installer 설치

# Response File (update_installer.txt)
-OPT silentInstallLicenseAcceptance="true"
-OPT installLocation="/home/wasadmin/IBM/WebSphere/UpdateInstaller"

./install -silent -options update_installer.txt

Step 3: Fix Pack 적용

Update Installer가 설치된 경로에서 실행합니다.

# Response File (install_fixpack.txt)
# 픽스팩 파일(.pak)이 위치한 디렉토리
-W maintenance.package="/home/wasadmin/was_img/fixpacks"

# 패치를 적용할 대상 제품 경로 (WAS, IHS, Plugin 중 택 1)
-W product.location="/home/wasadmin/IBM/WebSphere/AppServer"
# -W product.location="/home/wasadmin/IBM/HTTPServer"

# Update Installer 실행
cd [UpdateInstaller_HOME]
./update.sh -silent -options install_fixpack.txt

---

5. 제품 삭제 (Uninstallation)

설치된 제품을 제거할 때도 Silent Mode를 지원합니다.

실행 명령어

[WAS_HOME]/uninstall 디렉토리에서 실행합니다.

# 1. 기본 삭제 (프로파일 유지)
./uninstall -silent

# 2. 프로파일 포함 전체 삭제 (옵션 추가)
./uninstall -silent -OPT removeProfilesOnUninstall="true"

# 3. 프로파일 유지 명시
./uninstall -silent -OPT removeProfilesOnUninstall="false"

삭제 로그 확인

삭제 완료 후 [WAS_HOME]/logs/uninstall/log.txt 파일에서 INSTCONFSUCCESS 메시지를 확인합니다.