출처 : http://www.ibm.com/developerworks/kr/library/opendw/20061017/

웹 개발자에게 있어 톰캣은 JSP를 배우거나 간단한 테스트를 하는 정도의 웹 컨테이너로 생각하는 경우가 많다. 하지만 근래 들어 기업 및 대형 포탈에서 상용 서비스를 위한 웹 컨테이너로서 톰캣을 선택해, 성공적으로 적용한 사례들이 늘고 있다. 톰캣에서 안정적인 웹 서비스를 제공하기 위해서 지원하는 기능은 5가지가 있다. 아파치 웹서버와 연동, 로드밸런싱, 세션 클러스터링, 데이터베이스 처리, 모니터링 및 관리 등이 그것이다. 
이 문서에서는 로드밸런싱과 세션 클러스터링 위주로 설명을 할 것이며, 다음에 기회가 된다면 다른 부분에 대해서도 자세히 알아보도록 하겠다.

아파치 웹 서버와 톰캣의 연동

일반적으로 정적인 페이지를 서비스할 때는 웹서버가 훨씬 더 좋은 성능을 발휘한다. 또한 이렇게 역할 분담을 함으로 톰캣에 가중되는 부하를 줄여주는 효과도 얻을 수 있다. 아파치웹서버와 톰캣을 연동하는 것을 일반적으로 ‘커넥터(Connector)'라고 부르며, 여기에는 WARP 커넥터, JK 커넥터 그리고 JK2 커넥터가 있다. 이중에서 WARP와 JK2는 공식 커넥터에서 제외되었고 현재 남아 있는 것은 JK 커넥터뿐이다. 그럼 먼저 JK 커넥터를 이용해서 아파치 웹서버와 톰캣을 연동해 보도록 하겠다. 
아파치 웹사이트에서 바이너리 혹은 소스 코드를 다운로드 받도록 하자. 유닉스 혹은 리눅스는 mod_jk.so이며 윈도우용은 mod_jk.dll이다. 이 파일을 아파치 웹서버의 modules 디렉토리에 저장한다(주의, 아파치 웹서버를 컴파일해서 사용하는 경우는 컴파일시에 DSO 기능이 가능하도록 설정해줘야 한다). 저장을 한 후에 아파치 웹서버에 해당 모듈을 인식시켜야 하며 아파치 웹서버의 httpd.conf 파일에 다음 내용을 추가하도록 하자.

리스트 1. httpd.conf

        ...
LoadModule jk_module modules/mod_jk.so    # 모듈 추가
JkWorkersFile "conf/workers.properties"   # JK 설정 파일 위치 및 이름
 
JkLogFile "logs/mod_jk.log"               # JK에 대한 로그 파일 위치
JkLogLevel info                           # 로그 레벨 지정
JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"   # 로그 시간 포맷 지정
JkRequestLogFormat "%w %V %T"             # 로그 내용 포맷
JkMount /* loadbalancer                   # URL 링크 -> 모든 요청을 톰캣으로 지정
JkMount /servlet/* loadbalancer           # URL 링크 -> servlet 요청을 톰캣으로 지정
...

위와 같은 설정을 하게 되면 아파치 웹서버로 들어온 모든 요청을 톰캣으로 재전송 하게 된다. 만일 JSP와 서블릿만 톰캣에서 서비스를 하고 나머지는 아파치 웹서버에서 서비스 하고자 한다면 다음과 같이 수정하면 된다.

  
JkMount /*.jsp loadbalancer                # URL 링크 -> *.jsp 요청을 톰캣으로 지정 
JkMount /servlet/* loadbalancer           # URL 링크 -> servlet 요청을 톰캣으로 지정 

httpd.conf에는 위의 내용이 전부이다. 그럼 이제 workers.properties 파일을 작성해 보도록 하겠다. 이 파일이 실제 로드밸런싱을 위한 설정이 되겠다.

라운드 로빈 방식의 로드밸런싱 설정

톰캣에서 제공하는 로드밸런싱은 정확히 톰캣 자체에서 제공하는 것이 아니라 아파치 웹서버와 연동되는 커넥터에 의해서 제공된다(로드밸런싱은 JK, JK2 커넥터에서만 제공된다). 현재는 라운드 로빈(Round Robin) 방식만이 제공되며 로드밸런싱에 대한 설정은 workers.properties 파일에서 정의하게 된다.

리스트 2. workers.properties 

  
worker.list=tomcat1, tomcat2, loadbalancer
 
worker.tomcat1.type=ajp13
worker.tomcat1.host=localhost
worker.tomcat1.port=11009
worker.tomcat1.lbfactor=100
 
worker.tomcat2.type=ajp13
worker.tomcat2.host=localhost
worker.tomcat2.port=12009
worker.tomcat2.lbfactor=200
 
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=tomcat1,tomcat2

worker라는 개념은 톰캣의 프로세스로 보면 된다. 즉 worker를 설정하는 구성 요소는 JK 커넥터를 연결하는 방식(JK는 ajp13을 이용한다), 톰캣이 실행되어 있는 IP 혹은 도메인, ajp13 서비스 포트, 그리고 작업 할당량이다. 여기서 주의 깊게 볼 것이 작업 할당량인데 로드밸런싱 시에 lbfactor라는 작업량의 비율을 보고 라운드 로빈 방식의 서비스를 제공하게 된다. 여기서는 tomcat1과 tomcat2를 1대 2의 비율로 작업량을 할당한 것이다. 
그럼 이제 남은 작업은 2개의 톰캣 프로세스를 실행시키는 것이다. 톰캣 프로세스를 여러 개 띄우는 방법은 2가지가 있다.

• 톰캣을 2개 설치해서 기동시킨다. 이때 포트 충돌을 피하기 위해 서버 포트, AJP13과 HTTP 1.1 커넥터 포트 2개를 충돌되지 않게 재정의 한다.
• 하나의 톰캣에 2개의 서비스를 정의하고 톰캣을 기동시킨다. 이때 AJP13과 HTTP1.1 커텍터 포트 2개를 충돌되지 않게 재정의 한다.

먼저 2개의 바이너리를 설치했다고 가정하면 각각의 톰캣은 다음과 같은 형태의 server.xml 파일로 적용해 준다.

리스트 3. server.xml 

리스트 4. server.xml 

리스트 5. server.xml 

리스트 5는 하나의 톰캣 바이너리를 통해 2개의 프로세스를 실행시키는 것이다. 이렇게 하면 환경 설정의 편리성을 가져올 수 있지만 특정 서비스만 실행하거나 종료 시키는 것은 아직 지원되지 않는다. 즉 모든 서비스가 동시에 실행되거나 혹은 동시에 종료되는 것을 의미한다. 이런 점을 잘 판단해서 두 가지 형태의 환경 설정 중 하나를 선택하면 되겠다. 
지금까지는 로드밸런싱에 대해 알아보았다. 위의 환경설정을 가지고 테스트를 하다 보면 한가지 문제가 발생한다. 예를 들어 어떤 사용자가 tomcat1을 이용해서 쇼핑몰 서비스를 받고 있다가 tomcat1이 비정상 종료를 하게 되었다. 이때 사용자가 웹 페이지를 요청하게 되면 아파치 웹서버는 tomcat1이 종료된 것을 인지하고 그 이후부터 서비스를 tomcat2로 요청하게 된다. 하지만 tomcat1에 저장되어 있던 쇼핑바구니 정보 즉 세션 정보는 사라진 상태다. 즉, 서비스는 유지되지만 사용자는 다시 이유도 모르게 처음부터 쇼핑 항목들을 등록해야 하는 문제를 가지게 된다. 이제부터는 이런 문제를 해결할 수 있는 톰캣 프로세스 간의 세션 정보 공유에 대해서 알아보겠다.

세션 클러스터링 설정

클러스터링은 톰캣 5.x 버전부터 지원이 되고 있지만 아직은 초기 단계이고 세션 클러스터링만이 제공되고 있는 수준이다. 기능이 많이 부족하긴 하지만 로드밸런싱과 더불어 사용할 경우에는 좀 더 안정적인 서비스를 제공할 수 있다. 작업을 해주어야 할 것은 다음과 같다.

• server.xml에 <Cluster> 태그 정의
• 웹 어플리케이션의 web.xml에 <distributable/> 태그 추가

리스트 6. server.xml 

위로

웹 어플리케이션 작성을 통한 테스트

먼저 테스트를 위해서 간단한 웹 어플리케이션을 작성하도록 하겠다. 여기서 웹 어플리케이션 이름은 lbtest라고 하겠다.

리스트 7. index.jsp 

이상으로 톰캣을 이용한 로드밸런싱과 세션 클러스터링에 대해서 알아보았다. 일반적으로 로드밸런싱과 클러스터링은 성능 향상이라는 측면과 안정성 확보에 그 목적을 가지고 있다. 물론 고가의 상용 웹 어플리케이션 서버에 비하면 많이 부족하고 하드웨어를 이용한 로드밸런싱과 클러스터링에 비하면 안정성이 떨어질 수도 있지만 저렴한 비용으로 최대의 안정성과 성능을 얻고자 한다면 한번쯤 시도해 볼만한 좋은 기능이라고 할 수 있다. 아무쪼록 리눅스, 아파치, 톰캣 그리고 오픈소스를 통해 즐거운 웹 어플리케이션 개발 환경을 느껴보기 바란다.

위로

참고 자료
The Apache Tomcat Connector: http://tomcat.apache.org/connectors-doc/ 
Clustering/Session Replication HOW-TO: http://tomcat.apache.org/tomcat-5.5-doc/cluster-howto.html 

스위치의 분류 :

L2 : OSI 레이어 2에 속하는 MAC 어드레스를 참조하여 스위칭하는 장비

L3 : OSI 레이어 3에 속하는 IP주소를 참조하여 스위칭하는 장비

L4 : OSI 레이어 3~4에 속하는 IP 주소 및 TCP/UDP 포트 정보를 참조하여 스위칭하는 장비

L7 : OSI 레이어 3~7에 속하는 IP 주소, TCP/UDP 포트 정보 및 패킷 내용까지 참조하여 스위칭함

L4/L7 스위치의 용도 :

일반적으로 서버들의 로드밸런싱을 위해 사용됨

복수개의 웹서버가 있을 때, 임의의 웹서버에 접속을 시도하면, 스위치가 각 서버의 부하를 고려하여

적당한 서버와 연결시켜준다.

설정에 따라 순차적 연결 또는 접속이 가장 적은 서버에 연결하는 방식 등이 있다.

L4 스위치 :

Layer 4에서 패킷을 확인하고 세션을 관리하며, 로드밸런싱을 제공하는 스위치

TCP/UDP 패킷 정보를 분석해서 해당 패킷이 사용하는 서비스 종류 별로 처리(HTTP, FTP, SMTP...)

세션관리, 서버/방화벽 로드밸런싱, 네트워크 서비스 품질 보장

 

 

L7 스위치 :

L4 스위치의 서비스 단위 로드밸런싱을 극복하기 위해 포트 + 데이터 페이로드 패턴을 이용한 패킷 스위치

(e-mail 내용/제목, URL ...)

connection pooling(시스템 부하 감소), Traffic Compression (컨텐츠 압축 전송), 보안 기능

 

L4 vs L7 :

 

공통점 : 스위치로 들어온 패킷을 적절한 목적지로 전송해줌 (불필요한 패킷은 drop시킴)

차이점 : 

 

  기능과 역할은 동일하나 패킷을 분석하는 인텔리전스가 다름

  L7은 보안 기능 강화

  (DOS/SYN 공격 방어, CodeRed/Nimda 등 감염 패킷 필터링, 네트워크 자원 독점 방지 등)

L7 스위치에 대한 오해 :

 

  L7 스위치는 레이어 7 계층을 위한 스위치이다.

     : 기본적으로 L2, L3 및 부분적으로 L4 스위치를 지원한다. 레이어5 세션 계층 위주이다.

  L7 스위치는 URL 기반 스위치다.

     : L7 스위치 기능에 대한 일부분을 말한 것이다.

  L7 스위치는 모든 TCP/UDP 포트(0-65535)에 대한 인지가 가능하다.

     : 알려진 일반 포트에 대한 세션처리는 가능하지만, 순간적으로 사용하는 임시 포트는 제한적이다.

 

sticky session :

 

L4 스위치를 통해 분배된 서비스 세션은 하나의 연결 요청에 1~n 중에 한 대의 서버에 분배된다.

 

여러 번 시도해도 그 때마다 1~n 중에 한 대에 분배되므로, 같은 서버에 접속될 확률은 1/n이 된다.

 

그러나 처음에 접속했던 서버와 같은 서버에 계속 연결시킬 수 있다.

 

바로  sticky 옵션이다.

 

(일반적인 상태)

사용자A -> L4 -> 1번서버

사용자A -> L4 -> 3번서버

(sticky 상태)
사용자A -> L4 -> 1번서버
사용자A -> L4 -> 1번서버

기존 사용자의 세션 상태를 timeout 시간 내에는 계속 유지시켜주는 것이 sticky session이다.

timeout 시간은 60분 이내로 조절 가능하다.

 

 

sticky session의 문제점 :

L4 스위치의 가장 큰 목적(?)인 로드밸런싱이 제대로 동작하지 않을 수 있다.

 

개별 사용자가 사용할 경우에는 세션 timeout이 있으므로 어느 정도 로드밸런싱을 충족시킨다.

 

하지만 프록시서버를 사용하는 경우 문제가 된다.

 

예를 들어 회사에서 외부로 나가는 경우 각 PC의 IP가 아니라 프록시서버의 IP를 달고 나간다.

 

여러 사람이 timeout 시간 내에 접속하는 경우, 계속해서 한 서버에만 로드가 집중된다.

 

(외부에서 보기에는 동일한 사람으로 보이므로)

대안 :

SSL이나 기타 다른 보안모듈을 이용해서 인증된 특정 사용자에 대해서 Cookie/DB에 기록 후

 

해당 사용자에 대해서만 세션을 유지하도록 한다. (단점 : performance 저하 및 기타 cost)

 

그래서 L7 스위치를 사용한다.

 

< L7 스위칭 방식 >

URL 스위칭 :

URL 주소에서 특정 String을 검사하고, 검색된 문자열을 기준으로 부하를 분산시키는 방식이다.

 

http://www.test.com/test.html 이라는 주소로 사용자들이 웹페이지를 요청한다.

 

해당 페이지는 이미지가 빈번히 변경되고, 이미지 크기도 크다. (전체적으로 로딩이 느리다)

 

이런 경우, client의 http request 내용에 html이 들어가면, 메인 웹서버로 전송하고..

 

해당 request에 jpg 등의 이미지를 요청하는 경우 이미지 웹서버로 분산할 수 있다.

 

Cookie 스위칭 :

 

Http header의 cookie 값에 따른 특정 String을 기준으로 부하를 분산하는 방식이다.

 

Cookie 값 필드를 보고 설정된 분류 기준에 따라 어느 서버로 보낼지 결정한다.

 

Content 스위칭 :

 

legacy한 L7 스위칭은 URL/Cookie 스위칭을 사용했으나,

 

최근 L7 스위칭은 Content 스위칭 방식을 이용한다.

 

기존에는 제한적인 기능, 즉 호스트네임, URL, Cookie 를 기준으로 로드밸런싱을 하였으나,

 

L7 content 스위칭은 추가적인 기능을 지원한다.

 

  Http header 의 모든 필드를 기반으로 한다.

 

  XML content를 기반으로 한다.

 

  XML tags 나 multiple Http header를 기준으로 복잡한 로드밸런싱을 구현한다.

 

  Cookie 와 http header의 insertion과 deletion을 포함한 contents-rewrite 기능을 지원한다.

 

  alternate한 url이나 도메인의 redirecting request를 지원한다.

출처 : http://freeism.web-bi.net/tc/657

------------------------------------------------------------------------------------------

L4장비 로드 밸런싱 알고리즘

1. Hashing algorithm

Hashing (hash) 알고리즘에서는 새로은 연결(TCP/UDP)시 각 클라이언트에 대해 hashing key를 가지고 경로를 지정한다. Hashing key는 클라이언트의 IP + port 혹은 IP 주소만으로 결정된다.

장점 : 메모리를 적게 사용하고 요구 절차가 간단.

2. Round-robin algorithm

Round-robin 알고리즘은 round-robin 방식으로 경로를 지정한다. 모든 클라이언트는 동일하게 취급되며 실 서버 혹은 경로는 같은 처리량을 보유해야 한다. SLB에 많이 사용되며 만약 각기 다른 처리 능력을 가진 서버가 있을 경우 weigted round-robin 알고리즘이 더 효율적이다.

3. Weighted round-robin algorithm

Weighted round-robin 알고리즘은 서로 다른 처리 능력을 가진 서버가 있을 경우 사용한다. 가중치를 주어 많이 처리할 수 있는 서버로 많은 트래픽을 할당한다.

4. Least connection algorithm

이 알고리즘은 연결 수가 가장 적은 서버에 네트워크 연결방향을 정한다. 동적인 분산 알고리즘으로 각 서버에 대한 현재 연결 수를 동적으로 카운트할 수 있다.  동적으로 변하는 요청에 대한 부하를 분산시킬 수 있다.

5. Weighted least-connectin algorithm

이 알고르짐은 서버의 처리 능력을 고려하여 가중치를 부여하면서 least-connection scheduling을 적용하여 트래픽을 고루게 분산시키는 방법이다. 

--------------------------------------------------------------------------------------------

L4장비 사용( 로드밸런싱 사용 알고리즘 확인 필요)

1. 웹서버와 세션 유지시간 일치후 사용(sticky 옵션)

- 적절한 로드밸런싱이 이루어지지 않을 수 있음

> 단체에서 프록시 서버를 이용하는경우

- 라운드 로빈방식 보다는 hash방식에 적합

2. 세션 서버 사용

- 별도의 서버 필요(Redis, infinispan)

> 리소스 오버헤드

- 혹은 세션 클러스터링 설정(WAS, 라운드 로빈방식) 필요

3. 쿠키사용 

> 보안 이슈, 암호화 필요

> 부분 정보 쿠키 사용시 매번 api호출 오버헤드 발생

> 일부 쿠키 지원안하는 브라우저 사용유저 발생 가능성

Oracle 컬럼 암호화 (Transparent Data Encryption)

Oracle10g Release 2에서는 데이터의 암호화를 위하여 
Transparent Data Encryption (이하 TDE) 라는 기능을 제공한다.

이 기능의 특징은

1. 테이블의 컬럼별로 데이터를 암호화 할 수 있다.
2. 인덱스도 암호화 할 수 있으며, 인덱스에 암호화 하더라도 성능의 큰 저하는 없다
(Oracle에서는 Insert시 1.6배, Select시 1.4배의 저하가 생긴다고 함..수치 확인필요)
3. pl-sql로 암호화/복호화의 DDL을 재정의, 혹은 정의 할 필요가 없다.
4. 물리적인 데이터파일(dbf확장자 파일)의 도난에 안전하다.
5. 동일 Wallet으로 Data Dump의 import, export도 가능하다.
6. AES128, AES192, AES256, 3DE168(168비트 Triple DES알고리즘)로 암호화 가능.
7. Salt라는 기능으로 같은 값의 데이터를 다른 암호화된 데이터로 저장 가능.
8. 기존 테이블에 ALTER TABLE 테이블명 MODIFY (컬럼명 ENCRYPT)로 
   암호화 가능

이정도가 될 것 같다. 장점을 우선으로 나열했다.

구현 방법은

1. %ORA_HOME%\admin\SID 밑에 wallet이라는 폴더를 만든다
(디폴트로 해당 폴더가 생성되지 않는다. wallet을 저장하는 디폴트 폴더가 저기.)

2. ALTER SYSTEM권한이 있는 계정으로 로그인한다.
(SYSDBA계정으로 GRANT해도 되고, SYSDBA계정으로 로그인해도 됨)

3. ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY "비밀번호"; 입력
(비밀번호는 반드시 더블쿼테이션으로..)
(AUTHENTICATED 대신 IDENTIFIED로 해도 됐었던 기억이...)
※ 이때 wallet을 자동 생성 할 수 없다는 에러가 발생할 때
 → 1번의 폴더 생성확인 해 볼 것. 
     비밀번호를 영어대소문자, 숫자, 특수문자를 포함하는 8자리 이상으로 지정 해 볼 것.

4. 1번의 폴더에 물리적 wallet파일이 생성되었는지 확인

5. 4번으로 생성된 wallet이 자동으로 open되나, open되었는지 확인 (에러 확인)
(ALTER SYSTEM SET ENCRYPTION WALLET OPEN AUTHENTICRYPTED BY "비밀번호"; 여기서 비밀번호는 생성시의 비밀번호)
※ WALLET 닫기
→ ALTER SYSTEM SET ENCRYPTION WALLET CLOSE;

6. 테이블 생성 (컬럼 정의 시, 암호화 할 컬럼 맨 마지막에 ENCRYPT 정의)
ex) CREATE TABLE encryptedTable (col1 varchar2(10) ENCRYPT);
Primary key에 대해서는 SALT로 컬럼을 생성 할 수 없다.(ENCRYPT는 SALT가 기본)
그럴때는
CREATE TABLE encryptedTable (col1 varchar2(10) ENCRYPT NO SALT);

7. 기존 테이블을 수정 할 경우
ALTER TABLE 테이블명 MODIFY (컬럼명 ENCRPYT);

이것으로 기본 설정은 끝.

Tip!
1. 컬럼에 암호화 설정시, 암호화 방식을 설정 할 수 있다. (기본 AES192)
ex) ALTER TABLE 테이블명 MODIFY (컬럼명 ENCRYPT USING '방식');

2. 암호화된 컬럼의 암호화 설정 제거
ex) ALTER TABLE 테이블명 MODIFY (컬럼명 DECRYPT);

이제 평상시 대로 INSERT, UPDATE, DELETE, SELECT를 하면 된다.
쿼리의 결과로는 복호화되기 전의 암호화 된 데이터의 확인이 불가능하다.
WALLET을 CLOSE하고 DDL을 날리면 WALLET이 CLOSE되어 있다는 에러 발생.

※ TDE의 단점 
정당한 방법으로 로그인 한 유저에 대해서는 암호화 정책이 해당되지 않는다.

AjaxPlorer 의 사용법을 알아보도록 하겠습니다.

1. 화면 구성

전체적인 화면은 아래와 같이 되어 있습니다.

이걸 부분적으로 나눠보면 아래와 같이 되어 있습니다.

[상단]

메뉴를 가르키는 항목은 상단에 있습니다.

이 항목들은 아래 리스트에서 마우스 오른쪽를 누르면 나타납니다.

[폴더]

웹하드에 구성된 폴더를 볼 수 있습니다.

[정보 창]

웹하드에서 폴더 및 파일에 대한 정보를 볼 수 있습니다.

[파일 리스트 창]

파일을 업로드 하면 아래와 같이 리스트 창에 나타납니다.

처음엔 휴지통이 있지만, 파일을 생성하거나 올린 파일에 대해서 정보를 볼 수 있습니다.

2. 폴더 생성

파일을 올리기 위한 폴더를 생성을 해봅니다.

메뉴에서 3번째에 있는 새 폴더(N)를 선택해줍니다.

아래와 같이 '자료'라는 방을 생성해보도록 합니다.

파일 리스트 창에 폴더가 생성되었습니다.

요즘 서버에선 UTF-8을 잘 지원해줘서 그런지 한글 폴더명이 깨지지 않고 잘 나타납니다.

3. 업로드

이번엔 업로드를 테스트해 볼 차례입니다.

메뉴 항목의 업로드 메뉴를 선택합니다.

또는 리스트 창에서 마우스 오른쪽 버튼을 눌러서 업로드를 눌러줍니다.

웹 기반으로 만들어져서 그런지 마우스 오른쪽에서 쉽게 메뉴를 지원하도록 설정해놓은거 같습니다.

아래와 같이 업로드 창이 뜹니다.

왼쪽 위에 있는 [당신의 컴퓨터 탐색] 버튼을 눌러줍니다.

테스트로 'data.zip' 파일을 선택하도록 하였습니다.

업로드 하려는 데이터가 보입니다.

[전송] 버튼을 누르면 업로드가 진행됩니다.

아래 [옵션]에서 업로드 하자마자 바로 전송하게도 설정을 할 수 있습니다.

그리고 더 간단하게 마우스로 파일을 끌어다 놓으면 업로드가 활성화 됩니다.

오른쪽 아래 DROP FILES HERE 라는 메시지가 드래그로 쉽게 올릴 수 있음을 알려줍니다.

파일이 업로드가 되면 리스트에 나타나고 왼쪽 폴더 창과 정보 창에 파일에 대한 내용을 보여줍니다.

4. 다운로드

업로드를 했으니 다운르도를 해보도록 하겠습니다.

파일을 선택하면 상단 메뉴 창에 다운로드 버튼이 새로 생깁니다.

또는 파일 선택 후, 마우스 오른쪽 버튼을 눌러서 다운로드를 선택합니다.

다운로드 외에 압축을 풀거나 복사, 붙여넣기 같은 메뉴도 지원합니다.

다운로드를 누르면 일반 파일을 받는 것 처럼 다운로드를 시작합니다.

5. 파일 삭제

파일 삭제 역시 상단의 메뉴를 사용해보거나 마우스 오른쪽 버튼을 눌러서 삭제를 할 수 있습니다.

삭제를 하고 나면 목록에서 파일이 사라지고 리스트 아래 휴지통으로 이동되었다고 뜹니다.

파일을 완전 삭제하고 싶으면 휴지통에서 파일을 지워주면 됩니다.

윈도우 탐색기 형태의 웹하드
 - 사용자 계정 부여 및 권한 설정
 - 한국어 지원(옵션 조정)
 - 별도 프로그램 없시 사용가능

 * 설치 환경 :  php 5.2.11 이상 설치된 환경

제품 다운로드 : http://www.ajaxplorer.info/
ajaxplorer-core-2.6 다운로드 : ajaxplorer-core-3.1.1.zip

  -> 접속 후 첫 로그인 후 admin 계정의 암호를 필히 변경하여 주셔야 합니다.

  
  

우측 상단의 계정이름 옆 단추를 선택하여 환경 및 암호를 변경 합니다.

  


사용하여 보니 접속 및 동작이 php 환경의 한계 때문에 어려움이 있으나, 무료와 사용 제약의 강점때문에 무료웹하드 프로그램으로 추천합니다.


제품 설치 후 수정 사항

1.php.ini의 설정


max_execution_time = 14400 ( 시간 초과 되지 않게 설정을 변경)
max_input_time = 14400 ( 시간 초과 되지 않게 설정을 변경)
memory_limit = 128M  ( 업로드 용량에 따라 크게 설정)
upload_tmp_dir = "D:"(하드 공간이 충분 한 곳으로 변경)
post_max_size =2000M( 최대 업로드 용량설정 값보다 작게 설정합니다)
upload_max_filesize = 2048M( 1개 파일당 최대 2G로 설정했습니다)

2.conf.php의 설정

getSession(), getSession(true), getSession(false) 차이점

<meta name=“Author” content=“NOLS”> Author:제작자의 이름이 NOLS라는 뜻

<meta name=“Generator” content=“Microsoft FrontPage 4.0”> 페이지를 프론트 페이지로 제작

<meta name=“Copyright” content=“2003 RANGS”> 저작권에 관한 정보

<meta name=“Keywords” content=“html,tag,mata,메타,태그”> 검색엔진에서 검색되는 키워드

<meta name=“Description” content=“META 태그에 관한 정보”> 페이지에 대한 정보

<meta http-equiv=“Content-Type” content=“text/html; charset=euc-kr”> 문자 인코딩

<meta http-equiv=“Refresh” content=“60”> 60초 마다 새로고침

<meta http-equiv=“Refresh” ccontent=“5;url=주소”>주소로 5초후 이동

<meta http-equiv=“Pragma” content=“no-cache”> 캐쉬가 되지 않게

<meta http-equiv=“Expires” content=“Mon, 08 Sep 2003 10:10:10 GMT”> 캐쉬 만료(파기)일

<meta http-equiv=“Page-Enter” content=“revealtrans(duration=1,transition=12)”>페이지 들어갈때 트랜지션 효과(장면 전환 효과)

<meta http-equiv=“Page-Exit” content=“revealtrans(duration=1,transition=12)”>페이지 나갈때 트랜지션 효과(장면 전환 효과)

<meta http-equiv=“Imagetoolbar” content=“no”>이미지 마우스 오버시 이미지툴바 생기지 않게해줌

<meta http-equiv="refresh" content="5; url=main.html"> 페이지 이동

jquery ie7, ie6 json is undefined

<!--[if lt IE 7]><script type="text/javascript" src="js/json/json2.js"></script><![endif]-->

<!--[if IE 7]><script type="text/javascript" src="js/json/json2.js"></script><![endif]-->

<script type="text/javascript" src="js/jquery-1.8.2.min.js"></script>

스크립트를 포함시켜주면 된다.

http://www.devcurry.com/2010/12/resolve-json-is-undefined-error-in.html

https://github.com/douglascrockford/JSON-js

http://blog.naver.com/gogojinny80?Redirect=Log&logNo=110076620135

를 참고 하여 아래 명령어를 실행

하지만 실패..

왜이런 에러가 뜨는지 본에러 내용이 표출되었다.

ORA-01565

spfile을 불러 올 수 없어 에러가 나는것 같았다.

확실히 어제 nls_sort, nls_comp 파라메터를 추가 시켜주려고 수정했던것이 생각났다.

http://blog.naver.com/langve/80099521224

위 글로 부터

spfile : 환경변수를 저장한 2진 파일

pfile   : 환경변수를 저장한 텍스트 파일

 

파라미터 저장 파일 : [orahome]/dbs/spfile[sid].ora

                             8i 까지는 메모장같은것으로 위의 파일을 열어 수정 할 수 있었지만

                             9i 부터는 명령어를 통해서만 수정 가능하다.

                             파라미터 파일이 있어야 오라클이 구동 1단계를 커쳐 노마운트를 넘어 갈 수 있으므로

                             오라클이 구동되지 않고 v$ 내용마자 찾을 수 없다면 파라미터 파일을 고쳐야 한다.

이라는 정보를 얻었다.

어제 명령어로 수정한 spfile을 수정사항 복구를 위해 에디트플러스로 수정을 하여 발생했다는 원인을 파악 할 수 있었다.

그래서 에디트플러스로 파일을 열때 인코딩형식을 물어봤군..

이제는 손상된 spfile을 복구시키는 방법을 찾았다.

http://cafe.naver.com/oracle1004/108

http://blog.naver.com/meldin/60090587998

두글을 참고 하여 아래와 같은 절차를 통했다.

에러 해결.