레이블이 WebSphere인 게시물을 표시합니다. 모든 게시물 표시
레이블이 WebSphere인 게시물을 표시합니다. 모든 게시물 표시

WAS | WebSphere when native_stdout file capacity continues to increase

WebSphere when native_stdout file capacity continues to increase


OS : CentOS 7 3.10.0-957.el7.x86_64

issue

JVM-"Java"-Logs(SystemOut, SystemErr)의 경우 WebSphere에는 로그 순환을 허용하는 내장 메커니즘이 있다(시간 또는 크기 기반 접근법 또는 두 가지 접근법의 혼합). JVM-"프로세스"-Logs(native_stderr, native_stdout)의 경우 WebSphere에는 이러한 내장 메커니즘이 없다.

특히 native_stderr 파일을 로그 로테이션을 전하고자 하는 주된 이유는 일반적으로 가비지 콜렉션의 verbosegc(Verbose Garbassy Collection) 항목이 포함되기 때문이며, 이 파일은 수행된 모든 가비지 콜렉션(GC) 사이클과 관련 통계(예: GC 실행 전/후 메모리 양)의 레코드 저장소다. 이러한 verbosegc 레코드는 시간이 지남에 따라 크게 증가하므로 native_stderr파일은 상당히 커질수 있다.

  • 상세한 가비지 콜렉션 옵션 On

Solution plan

JVM의 -Xverbosegclog 옵션을 활용해서 GC 로그를 별도로 생성 하는 방식으로 우회해서 사용할 수 있다.

  • 상세한 가비지 콜렉션 옵션 Off
  • JVM -Xverbosegclog 설정 구문
    -Xverbosegclog[:<filename>[,<x>,<y>]]

where <file> specifies a base filename, <X> is the number of files being used and <Y> is the number of GC cycles contained in one file (before rollover).

-verbose:gc
-Xloggc:${SERVER_LOG_ROOT}\verbosegc.log
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=10
-XX:GCLogFileSize=10M
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails

예)

-Xverbosegclog:/app/was/gclogs/websphere/server1/gc.%Y%m%d.%H%M%S.%pid.txt

WAS | WebSphere 전체 Log4j 보안 취약점 관련 내용 정리

WebSphere 전체 Log4j 보안 취약점 관련 내용 정리

Security Bulletin: Multiple vulnerabilities in Apache log4j affect the IBM WebSphere Application Server and IBM WebSphere Application Server Liberty (CVE-2021-4104, CVE-2021-45046)


Affected Products and Versions

Affected Product(s) Version(s)
WebSphere Application Server Liberty Continuous delivery
WebSphere Application Server 9.0
WebSphere Application Server 8.5
WebSphere Application Server 8.0
WebSphere Application Server 7.0

관련 취약점 내용

아래의 이슈 사항을 확인 해보면 되지만 간략하게 정리 했습니다. 전체 플랫폼의 이슈되는 APP는 UDDI.ear 이면 기본적으로 구성을 위해 별도의 설치가 필요합니다.(미 사용중이라 영향도 없음)

결국 9.x kc.war 문제가 되며 해당 APP 경우 관리콘솔 도움말에 사용중 인 것으로 보이며, 문제가 되는 클래스 제거하거나 라이브러리를 제거 하는 식으로 임시 조치를 취하고 있습니다.

1. WebSphere Application Server traditional release 9.0 only:

Remove <WAS_HOME>/systemApps/isclite.ear/kc.war/WEB-INF/lib/log4j*.jar from any system running the WebSphere admin console and restart the application server.
Note: If any future service (prior to 8.5.5.21 or or 9.0.5.11) is applied to the install the log4j files will be restored without warning.
If the kc.war application has been installed then uninstall it. For instructions on how to determine if kc.war is installed see question Q9 in our Log4Shell (CVE-2021-44228) FAQ.
Remove <WAS_HOME>/installableApps/kc.war

2. All WebSphere Application Server traditional releases:

Users of the UDDI Registry Application: Remove log4j*.jar from within the <WAS_HOME>/installableApps/uddi.ear
archive and update (redeploy) any installed (deployed) copies of the UDDI Registry application.
Users who do not use the UDDI Registry Application should remove <WAS_HOME>/installableApps/uddi.ear

IBM 보고된 내용 링크
https://www.ibm.com/support/pages/node/6526750

3. Log4j 1.x 추가 사항

웹스피어의 경우 이경우가 UDDI.ear 따로 해당 기능을 사용하지 않으면 추가적인 조치가 필요 없음)

Is Log4j 1.x vulnerable

There is still a lot of information coming out surrounding Log4Shell. At the time this blog was published, Apache said that Log4j 1.2 is vulnerable in a similar way when Log4j is configured to use JMSAppender, which is not part of the default configuration, but is not specifically vulnerable to CVE-2021-44228. This vulnerability in Log4j 1.2 has been assigned CVE-2021-4104.

Is there a patch available for Log4j 1.2?

No, Log4j branch 1.x has reached end of life (EOL) status, and therefore does not receive security updates. Users are instructed to upgrade to Log4j 2.12.2 (for Java 7) or 2.16.0 or greater.

How do I address CVE-2021-4104?

There are a few mitigation options that can be used to prevent exploitation of CVE-2021-4104.

  • Do not use the JMSAppender in the Log4j configuration
  • Remove the JMSAppender class file (org/apache/log4j/net/JMSAppender.class)
  • Limit OS user access to prevent an attacker from being able to modify the Log4j configuration

WAS | WebSphere 보안 취약점 관련 access Log 설정

WebSphere 보안 취약점 관련 access Log 설정


Test Environment

  • Test Version : WebSphere v8.5

NCSA access Log and HTTP error log set up

HTTP Access

  1. 전체 로그 설정
  • Click Servers > Server Types > WebSphere application servers > server_name > NCSA access and HTTP error logging.
  • Select Enable logging service at server start-up.
  • Ensure that Enable access logging is selected.
  1. 컨테이너별 로그 설정 part 1
  • Application servers > server1 > Web container transport chains > HttpQueueInboundDefault > HTTP inbound channel (HTTP_2)
  • Select Enable logging.
  1. 컨테이버별 로그 설정 part 2
  • Application servers > server1 > Web container transport chains > WCInboundDefault > HTTP inbound channel (HTTP_2)

로그 포맷 변경시

참조 링크

https://www.ibm.com/support/knowledgecenter/ko/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/ttrb_access_logging.html

설정 위치

  • Go to the custom properties page for the wanted transport chain. Click Servers > Server Types > WebSphere application servers > server_name > Web Container Settings > Web container transport chains > chain_name > HTTP_channel_name > Custom properties.

  • Costum properties

    • key

    accessLogFormat

    • value

    %h %u %t "%r" %s %b %D "%{Referer}i" "%{User-agent}I" %{JESSIONID}C
    %h %i %u %t "%r" %s %b %D

SSL | WebSphere TLS Clearing issues

WebSphere TLS Clearing issues

Is TLS v1.2 supported in WebSphere Full Profile 7.0, 8.0, 8.5? What's minimum fix pack?

Answer: TLsv1.2 Suppport on V7.0.0.23 on wards TLsv1.2 Support on 8.0.0.3 onwards and 8.5.0.0.

  • TLS v1.2 supported in WebSphere with following JDK version. 7.0.0.23 comes JDK version as follows and TLSv1.2 supported SDK 6
    (32-bit) pap3260sr10fp1-20120321_01(SR10 FP1)
    (64-bit) pap6460sr10fp1-20120321_01(SR10 FP1)​

  • 8.0.0.3 comes with JDK version follows and TLSv1.2 supported
    SDK 6.0.1 (J9 2.6)
    (32-bit) pap3260_26sr1fp1-20120309_01(SR1 FP1)
    (64-bit) pap6460_26sr1fp1-20120309_01(SR1 FP1)

  • 8.5 comes with JDK version follows and TLSv1.2 supported
    SDK 6.0.1 (J9 2.6)
    (32-bit) pap3260_26sr2ifix-20120419_02(SR2+IV19661)
    (64-bit) pap6460_26sr2ifix-20120419_02(SR2+IV19661)

This change allows TLS 1.1 and 1.2 to be configured at the webserver plugin in 8.0 and later on distributed platforms.

  • TLS 1.1 and 1.2 is not supported on zOS at this time.
  • Despite this APAR being listed in 7.0 fixpacks, 7.0 does not support TLs1.1 and TLS1.2 due to the use of GSKit V7.

WAS

Click Security > SSL configurations CellDefaultSSLsetting , NodedefaultSSLsetting and any other SSLConfig

1. Select each SSL Configuration described above, then click Quality of protection (QoP) settings under Additional Properties.

2. On the **Quality of protection (QoP)** settings panel, select TLSv1.2 from the pull-down list in the box named Protocol. change the protocol to TLSV1.2

3. update ssl.client.props
This must be done for each **ssl.client.props** file under the following directories:
For Node example WAS_install\profiles\AppSrv01\properties
For DMGR example WAS_install\profiles\Dmgr01\properties

 **com.ibm.ssl.protocol=TLSv1.2**

4. stopNode.sh && stopManager.sh 

5. startManager.sh

6. syncNode.sh dmgrhostname dmgrsoapport -username userid -password password

7. startNode.sh

8. Click Protocol : openssl s_client -connect webspherehostname:9443 -tls1_2

WEB

update httpd.conf

VirtualHost
SSLProtocolEnable TLSv12
SSLProtocolDisable SSLv2 SSLv3 TLSv10 TLSv11

Plg

Why do I receive a GSK_ERROR_SOCKET_CLOSED (gsk rc = 420) error, when WebSphere Application Server and IBM HTTP Server are configured to use TLSv1.2? Answer: you need to have StrictSecurity="true" in the plugin-cfg.xml for TLSv1.2 to work. More details see the following link

WAS | Liberty Core installUtility command

To use the Liberty installUtility command.


version : IBM Liberty Core 20.0.0.6 OS : CentOS 7.2


feature Search

# installUtility find {feature_name} --type=feature

feature Download

# installUtility Download {feature_name} --location={download_path} --acceptLicense

repositories

저장소 저장을 위해 repositories.properties 작성

properties file path ${wlp.install.dir}/etc/repositories.properties file.

# feature download path or featue zip path
local-rep.url=/SW/img/LibertyUtility

viewSettings

testConnection

저장소 연결 테스트

# installUtility testConnection default

fixpackCenter feature Download

wlp Info Center
feature fix

WAS | WebSphere v9.0.5.1 Basic install guide

WebSphere v9.0.5.1 Basic install guide


OS : CentOS 7 3.10.0-957.el7.x86_64

IM imcl install

tip. Check the package name simply {img_file}/Offerings

IM install

./imcl install com.ibm.cic.agent -repositories "/sw/img/im/repository.config" -installationDirectory "/sw/IBM/InstallationManager/eclipse" -sharedResourcesDirectory "/sw/IBM/IMShared" -acceptLicense -sP

In this guide, use the existing Installation Manager.

# cd /sw/IBM/InstallationManager/eclipse/tools

WebSphere install

./imcl install com.ibm.websphere.BASE.v90_9.0.5001.20190828_0616 -repositories "/sw/img/base" -installationDirectory "/sw/was/AppServer9" -sharedResourcesDirectory "/sw/IBM/IMShared" -acceptLicense -properties cic.selector.nl=ko -sP

tip. Starting with websphere version 9.0, Java installation should also proceed.

#install
./imcl install com.ibm.websphere.BASE.v90_9.0.5001.20190828_0616 com.ibm.java.jdk.v8_8.0.5041.20190924_1031 -repositories "/sw/img/base","/sw/img/sdk" -installationDirectory "/sw/was/AppServer9" -sharedResourcesDirectory "/sw/IBM/IMShared" -acceptLicense -properties cic.selector.nl=ko -sP

#fix install
./imcl install com.ibm.websphere.BASE.v90_9.0.5003.20200226_0941 -acceptLicense -installationDirectory "/sw/was/AppServer9" -repositories "/sw/img/fixwas"  -sP

IBM HTTPServer install

./imcl install "com.ibm.websphere.IHS.v90_9.0.5001.20190828_0616" "com.ibm.java.jdk.v8_8.0.5041.20190924_1031" -repositories "/sw/img/ihs","/sw/img/sdk"  -installationDirectory "/sw/web/IHS9" -sharedResourcesDirectory "/sw/IBM/IMShared" -acceptLicense -sP -properties user.ihs.httpPort="80"

#fix
./imcl install com.ibm.websphere.IHS.v90_9.0.5003.20200226_0941 -acceptLicense -installationDirectory "/sw/web/IHS9" -repositories "/sw/img/fixweb" -sP

Plugins install

./imcl install com.ibm.websphere.PLG.v90_9.0.5001.20190828_0616 com.ibm.java.jdk.v8_8.0.5041.20190924_1031 -repositories "/sw/img/plg","/sw/img/sdk"  -installationDirectory "/sw/web/Plugins9" -sharedResourcesDirectory "/sw/IBM/IMShared" -acceptLicense -sP

#fix
./imcl install com.ibm.websphere.PLG.v90_9.0.5003.20200226_0941 -acceptLicense -installationDirectory "/sw/web/Plugins9" -repositories "/sw/img/fixweb" -sP

version Info

  1. imcl listInstalledPackages
  2. {install_home}/bin/versionInfo.sh

WAS | How to disable server name header

WebSphere - How to disable server name header

Test Version

  • Test OS : CentOS 7.2
  • Test WAS : WebSphere v8.5

X-Powered-By disable setting

  • 보안 취약점 사항

  • IBM HTTPServer (apache)
    This can be mitigated by adding (httpd.conf):

AddServerHeader Off
ServerTokens Prod
ServerSignature Off
  • WebSphere
    v8.5.0.2 이하 버전에서는 두가지 옵션으로 server version 노출을 방지.

  • ServerHeaderValue :
    Use the ServerHeaderValue property to replace the default value of the Server header that is added to all outgoing HTTP responses by server if a Server header does not already exist. The default value for the Server header is WebSphere Application Server v/x.x, where x.x is the version of WebSphere Application Server that is running on your system.

  • RemoveServerHeader :
    Use the RemoveServerHeader property to force the removal of any server header from HTTP responses that the application server sends, thereby hiding the identity of the server program.

setting link : https://www.ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/rrun_chain_httpcustom.html

Starting with Version 8.5.0.2, a Server header is no longer automatically added to all outgoing HTTP responses if a Server header does not already exist. If you add this property with a value, that value is included in the Server header that appears in the response. If you specify the value DefaultServerValue, WebSphere Application Server v/x.x is used as the Server header value.

WebSphere - How to disable X-Powered-By header

WebSphere - How to disable X-Powered-By header

Test Version

  • Test OS : CentOS 7.2
  • Test WAS : WebSphere v.8.5

X-Powered-By disable setting

  • 보안 취약점 사항

You can set the property 'com.ibm.ws.webcontainer.disablexPoweredBy' to true as described in the section

setting link : https://www.ibm.com/support/knowledgecenter/ko/SSAW57_8.5.5/com.ibm.websphere.nd.multiplatform.doc/ae/rweb_custom_props.html#com.ibm.ws.webcontainer.DisableXPoweredByHeader

설정 이후 서버 재 기동 필요.

WebSphere 디렉토리 리스팅 제거

WebSphere 디렉토리 리스팅 제거

Test Environment

  • Test OS : CentOS 7.2
  • Test Version : IBM HTTPServer v8.5.0.0

fileServingEnabled 기본값이 false이지만 보안 취약점으로 잡힌다면 아래와 같이 xml, xmi에 직접 적용 디렉토리 리스팅 제거

  1. ibm-web-ext.xmi ibm-web-ext.xml 예제:

    • enable-directory-browsing value="false"
  1. 웹 컨테이너 설정
    (서버 > 서버 유형 > WebSphere Application Server > server_name > 웹 컨테이너 설정 > 웹 컨테이너)

  2. fileServingEnabled, directoryBrowsingEnabled

이름 기본값
fileServingEnabled true
directoryBrowsingEnabled false

WebSphere에서 OS hostname 변경시 작업 사항

hosname이 변경될 경우 해당 Node의 serverindex.xml파일을 전부 변경 해주어야 한다.
* serverindex.xml 파일의 hostname수정
  ND의 경우 [WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/nodes
  Base의 경우[WAS_HOME]/profiles/[App Profile]/config/cells/[Cell_Name]/nodes(Base의 경우 해당 AppSrv만 수정)
*ND의 경우에는 dmgr과 노드 연합을 이루고 있는 각각의 노드의 모든 serverindex.xml 수정
*serverindex.xml 파일의 기존 hostname 이 남아 있는 경우에는 구동하더라고 시작 안됨
*hostname 변경시 serverindex.xml 파일만 수정 해도 구동이 가능

 

shell script 이용해서 'target'(old_host_name) 을 $1 (new_host_name) 으로 변경

find ./AppServer -type f | xargs grep -l 'target' > f.txt
        for file in `cat f.txt`
        do
        cat $file | sed "s/target/$1/g" > f1.txt
        mv f1.txt $file
        done

그 중 IBM에서 소개하고 있는 여러가지 방법은 아래 link를 참고하면 많은 도움이 될듯하다.
The WebSphere Contrarian: Changing host names and migrating profiles in WebSphere Application Server
AdminTask 오브젝트에 대한 NodeConfigCommands 명령 그룹
추가적으로 fixpack v6.1.0.25 이상 update 권고...
PK83773: THE ADMINTASK.CHANGEHOSTNAME COMMAND INCORRECTLY MODIFIES THE MULTICAST ENDPOINTS IN SERVERINDEX.XML
fixpack v7.0.0.13 이상 update 권고.
PM13373: UNABLE TO GENERATE CERTS USING REGENDEFAULTCERT OPTION USING WSADMIN ADMINTASK.CHANGEHOSTNAME COMMAND
결론적인내용은다음과 같다.
위치: {Profile_Root}/{Profiles_name}/bin
# ./wsadmin.sh -conntype NONE -lang jython
wsadmin> AdminTask.changeHostName(‘[-nodeName <node_name> -hostName <new_host_name>]‘)
wsadmin> AdminConfig.save()
wsadmin> quit

ND edition은 #./syncNode.sh 로 처리하는 센스.
[출처] [WebSphere] hostname 변경하기|작성자 jaejeongk
[Node Name 변경]===================================================
Dmgr start
변경하고자 하는 해당 profile > bin 디렉토리 아래에서 renameNode.bat(sh) 실행(실행시 해당 node 아래 있는 프로세스 중지)
사용 예)[WAS_HOME]/profiles/[App Profile]/bin>renameNode.bat [dmgr hostname] [dmgr SOAP_CONNECTOR_ADDRESS port] [new_node_name] -username admin -password admin (보안 설정이 되어 있는 경우 해당 user와 password 입력)
[Cell Naem 변경]====================================================
* 셀이름 변경 - 아래 명시된 파일에서 기존 셀 이름으로 되어 있는 것을 찾아서 수정한다.
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells 아래 있는, 셀 이름으로 된 디렉토리 이름 수정
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/cell.xml
[WAS_HOME]/profiles/[Dmgr Profile]/bin/setupCmdLine.bat
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/security.xml
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/variables.xml
    아래 두개는 웹 어드민 콘솔 관련 어플리케이션이다.
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/applications/isclite.ear/deployments/isclite/deployment.xml
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/applications/isclite.ear/deployments/isclite/isclite.war/WEB-INF/components.xml
* 각 노드(프로파일)에 있는 위의 파일들(isclite.ear 아래 있는 것들 제외-이것은 어드민 콘솔 관련 어플리케이션이라서 다른 노드에는 없다) 수정

[dmgr Node name 변경]================================================
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/nodes 아래 있는 디렉토리 이름 수정
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/nodes/VicCellManager03/node.xml
[WAS_HOME]/profiles/[Dmgr Profile]/bin/setupCmdLine.bat
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/security.xml
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/applications/isclite.ear/deployments/isclite/deployment.xml

[CoreGroup & NodeGroup name 변경]========================================
*코어 그룹과 노드 그룹은 기본적으로 DefaultCoreGroup, DefaultNodeGroup 이름으로 생성이 되는데, 사용자가 추가적으로 생성해 준 것이 있다면 이에 따른 파일들도 수정해 줘야 한다.
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/coregroups/DefaultCoreGroup/coregroup.xml
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/nodegroups/DefaultNodeGroup/nodegroup.xml

[etc name 변경]======================================================
[WAS_HOME]/profiles/[Dmgr Profile]/config/templates 아래 있는 파일들 중 기존의 노드 이름이 되어 있는 파일
(이 파일들은 수정하지 않아도 운영사에 지장이 없어 보인다)
*각 노드(프로파일)에 있는 아래 내용 수정
[WAS_HOME]/profiles/[Dmgr Profile]/config/cells/[Cell_Name]/nodes  아래 있는 디렉토리 이름 수정
[WAS_HOME]/profiles/[App Profile]/config/cells/[Cell_Name]/security.xml
=================================================================

*해당 작업 수행 후 플러그인 파일 생성 후 재 배포 실시
[HTTPServer_HOME]/bin apachectl.sh restart
*windows 의 경우 해당 서비스 재 시작




















WebSphere WEB - WAS 동적, 정적 컨텐츠 구분

web,wasfile

WEB - WAS 동적 & 정적 구분


Test Environment

  • Test OS : CentOS 7.2
  • Test Version : IBM HTTPServer v8.5, WebSphere v.85

WebSphere에서 컨텐츠 구분을 위해 작업해줘야 하는 사항

사실 별다른 설정없이 Plugin에 Uri 패턴설정만 해줘도 상관은 없다.

  1. Plugin-cfg.xml 파일을 커스트마이징해서 전체 request에 대한 Uri 매핑을 만들게 되면 당연히 WebServer에서는 모든 request를 WAS로 전달
  • 위치 : F:\IBM\HTTPServer\Plugins
  • 수정 : Plugin-cfg.xml 수정 부분
   <UriGroup Name="default_host_server1_root-PCNode01_Cluster_URIs">
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/> 
   </UriGroup>

해당 설정을 해주게 되면 설정된 패턴부분만 WAS로 넘기고 나머지는 WEB에서 찾게 된다.

  • httpd.conf 파일에 Alias 추가

    (/home/images에 이미지 파일이 복사돼 있어야 합니다.)

    위치 : F:\IBM\HTTPServer\conf

    추가 : Alias /images /home/images
  1. WebSphere 에서는 fileServingEnabled을 이용한 동적 & 정적 구분

WebSphere 에서는 fileServingEnabled 이라는 옵션을 해당 어플리케이션의 .ear/WEB-INF/ibm-web-ext.xmi 에 줄수 있는데 fileServingEnabled=“true” 로 하면 WAS 에서도 *.html 같은 정적 파일을 처리하고 “false” 로 하면 동적 컨텐츠만 처리하고 나머지 부분은 웹서버에서 처리하게 된다.

  • fileServingEnabled=“true” => "false"값을 변경후에는 해당 어플리케이션의 모든 파일을 수정해 주어야 한다.

위치 :

/WebSphere/AppServer/profiles/[Profile_Name]/config/cells/[Cell_Name]/applications/[Application_Name].ear/deployments/[Application_Nam]/[Application_Name].war/WEB-INF

/[Application Source Path]/[Application_Name].war/WEB-INF

수정 : ibm-web-ext.xmi

변경 : fileServingEnabled=“false”

수정 : ibm-web-ext.xml인 경우

변경 :

  • 플러그인 재 생성 후 전파(WebServer가 분리 되어 통신이 안되는 경우 해당 WebServer의 Plugin-cfg.xml 위치에 넣어 준다.)

    예)F:\IBM\HTTPServer\Plugins\config\webserver1\Plugin-cfg.xml

    변경된 Plugin-cfg.xml 파일을 확인 할수 있다.
   <UriGroup Name="default_host_server1_root-PCNode01_Cluster_URIs">
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsp"/>
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsv"/>
      <Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*.jsw"/>
   </UriGroup>
  • httpd.conf 파일에 Alias 추가

    (/home/images에 이미지 파일이 복사돼 있어야 합니다.)

    위치 : F:\IBM\HTTPServer\conf

    추가 : Alias /images /home/images

이렇게 두가지 방법으로 Plugin-cfg.xml 파일을 수정 후에는 해당 WebServer을 restart

  • WAS에서 모든 처리을 다할 경우 Plugin-cfg.xml의
<Uri AffinityCookie="JSESSIONID" AffinityURLIdentifier="jsessionid" Name="*"/>  



이 블로그 검색

Popular Posts

WEB&&WAS

OS

Reviews