|
|
1.
호스팅 이용 시 기본제공환경은 어떻게 되나요? |
|
|
| |
현재 미래와사람들 환경은 다음과 같습니다.
- MySql 3.22.32 ~ 3.23.58
- Apache 1.3.24 ~ 1.3.27
- Php 4.2.0 ~ 4.3.3
- Perl 5.6.0
- Jdk 1.3.1-03
- J2sdkee 1.3.1
- Tomcat 3.3.1 ~ 4.1.29
- Qmail 1.3
- mysql jdbc driver 2.0.11
지원되는 CGI 언어는 java,
php, perl입니다.
저희 기본 정책은 가능한 한 다양한 CGI를 지원하면서 장차 지원환경을
분리하는 것입니다.
위의 서비스 중 일부는 서버별로 통합되어 있고 일부는 분리되어 있으며
앞으로 고객님들의 사용패턴별로 최대한의 편의를 고려하여 환경 구성을 유동적으로
구성할 계획입니다.
|
|
|
2.
미래와 사람들에서는 어떤 프로그램들이 제공되나요 ? |
|
|
| |
미래와 사람들에서는 고객님들의 사이트 구축 편의를 위해 앞으로 가능한한 많은 애플리케이션을 제공함을 원칙으로 하고 있습니다.
현재 스킨형 게시판 호호보드를 제공하고 있으며 방명록 및 기타 프로그램들은 차후 확충하여 제공할 계획입니다.
게시판에 관한 상세한 설명은 아래의 스킨을 참조하시고 MyPage의 게시판 설치부분에서 자세한 정보를 얻으실 수 있습니다.
|
|
|
3.
게시판 스킨 미리보기 [Tomcat 3.X] |
|
|
| |
현재 제공되는 스킨은 10가지 종류가 있습니다. 스킨은 사용자가 변경하여 사용할 수 있습니다.
설치 및 이용에 관한 상세한 내용은 My Page --> 게시판 설치 부분을 참조하시면 자세한 설명을 보실 수 있습니다.
설치가 번거롭게 여겨지시는 분들은 성함과 계정명을 기재하여 tech@humanfuture.co.kr 로 설치요청해 주시면 기술지원팀에서 기본 세팅을 해드립니다.
|
| |
|
|
|
| |
기본적으로 로컬보다 서버에서 직접 개발하는 것이 운용에 가장 빠른게 사실입니다.
하지만 개발에서 클래스는 많이 변경되기 마련이고 이러한 클래스 변경 시 서블릿
엔진의 리스타트가 필요합니다.
하지만 잦은 엔진의 리스타트는 실제 안정화되어 운용중인 사이트들에는 세션이
끊긴다든지 프로그램의 오류 등이 발생할 수 있으므로 바람직하지 않은 정책입니다.
그러므로, 미래와사람들은 안정화된 운용에 중점을 두어
톰캣엔진은 1일 1회 사용자의 사용이 많지 않은 새벽대(현재 05시 전 후) 리스타트를
원칙으로 하고 있습니다.
로컬의 윈도우 환경에서도 apache-tomcat-mysql환경 구성이 가능하니
사이트 개발은 주로 로컬에서 하시고 인코딩과 DB 커넥션에 관한 부분만 일괄
수정해서 서버에 올리는 방식을 권유해 드립니다.
|
|
|
5.
클래스를 사용하고자 할 때는 어떻게 해야 하나요? |
|
|
| |
현재 각 유저들에 해당되는 클래스 패스는 해당 계정내의 WEB-INF/classes/가
적용됩니다.
따라서 각 유저들은 사용할 클래스를 classes에 두시면 됩니다.
jar를 사용할 경우 여기에 풀어서 사용하시면 되며 jar를 클래스 패스에
적용하고자 할시 별도의 설정이 필요하게 됩니다.
클래스 패스를 적용시 디렉토리를 적용하게 되면 해당 디렉토리 이하의 모든 클래스가
적용이 되나 jar를 적용하고자 할 시는 특정 jar에 대해 클래스 패스를
지정해야 합니다.
이는 관리자가 설정해야 하며 모든 유저들에 대해 이를 관리하는 것은 관리상의
어려움이 있습니다.
이점 양해하시고 jar를 클래스 패스에 적용하고자 할시 classes/ 에
풀어서 사용해 주시면 감사하겠습니다.
|
|
|
6.
서블릿을 사용하려면 어떻게 해야 하나요? |
|
|
| |
서블릿을 사용하고자 할 시는 classes 밑에 해당 서블릿파일을 두시고 request를
/servlet/서블릿명(.class 제외)과 같이 요청하시면 됩니다.
WAS에서와 같이 컨프에 alias설정은 설정은 필요없으므로 유저들은 바로
클래스 패스를 해당 위치에 두시고 클래스를 사용하실 수 있습니다.
|
|
|
7.
클래스 적용시점을 알고 싶습니다.[Tomcat 3.X] |
|
|
| |
클래스를 사용 시 각 사용자별 클래스를 WEB-INF/classes에 위치시키면
바로 적용이 됩니다.
그 클래스를 수정하면 변경 시 서버가 리스타트 되어야 변경사항이 적용이 됩니다.
그러므로, 개발중인 사이트의 경우에는 jsp-servlet엔진이 수시로 리스타트
되어야 하지만 운용중인 사이트의 경우에는 바람직하지 않습니다.
그리하여 미래와 사람들은 엔진을 1일 1회 리스타트 하며 리스타트에 걸리는
시간은 매우 짧습니다.(약 30초 이내)
검증이 충분히 된 배포 클래스의 경우에는 바로 올려서 사용하시면 되고
본인이 스스로 개발하시는 클래스의 경우에는 로컬에서 클래스의 메소드 테스트를
완료한후 올리시는게 바람직합니다.
자신이 직접 컨트롤 할 수 있는 환경이 아니라 웹호스팅과 같이 여러 사용자와
함께 사용해서 톰캣제어를 공동의 룰을 따라야 하는 경우 되도록 오류가능성이
적은 부분만 메소드화 해서 빈 검증을 완료한 후 사용하고 수시로 디버깅을 해야
하는 부분들은 되도록 jsp에서 구현하는게 바람직합니다.
실제로 운용하면서 수시로 수정해야 하는 사이트의 경우는 아예 jsp로 개발하는게
운용및 개발자의 편의가 증대되는 부분도 있습니다.
물론 클래스의 재사용성을 활용할 수 없는 측면이 있지만 웹호스팅 환경에서는
활용해볼만한 방향입니다.
그리하여 클래스를 사용하고자 할 때는 충분히 메소드 검증을 완료한 후 해당
디렉토리에 올리시는 방향으로 하시기 바랍니다.
|
|
|
8.
JDBC 드라이버 및 커넥션 사용방법은 어떻게 되나요?[Tomcat 3.X] |
|
|
| |
커넥션 사용방법은 아래와 같습니다.
String dbname = "jdbc:mysql://localhost/제공된DB명";
String user = "제공된아이디";
String password = "제공된패스워드";
Connection con = null;
try{
Class.forName("org.gjt.mm.mysql.Driver");
con = DriverManager.getConnection(dbname,user, password);
}catch(SQLException e){
// do something
}
현재 mysql 드라이버는 모든 jsp-servlet 사용
고객들이 사용하는
모듈이므로 공통모듈로 설정하였습니다.
따라서 별도로 드라이버를 획득하여 풀지 않으셔도 사용하실 수 있습니다.
jdbc 드라이버 버전은 2.0.11 입니다.
|
|
|
| |
경로는 로컬 윈도우 계열은 디렉토리 구분자가 \ 인데 리눅스에서는 / 를 사용하는데
따라 에디터에서 작업한후 소스를 올릴때에는 경로를 약간 수정합니다.
링크는 크게 두가지를 사용하실 수 있습니다.
public_html/test.html이 있고
public_html/test/test2.html이 있는 경우
test.html 소스내에 test2.html로
가는 링크를 포함 시 다음의 두가지와 같이 합니다.
1. 절대경로 사용 시
(public_html기준)
<a href="/test/test2.html> test2가기</a>
2. 상대경로 사용 시
(test.html기준)
<a href="test/test2.html> test2가기</a>
혹은
<a href="./test/test2.html> test2가기</a>
|
|
|
10.
jsp 한글 사용 방법[Tomcat 3.X] |
|
|
| |
미래와 사람들 고객 계정은 Apache 1.3.24 - Tomcat3.3.1 - mysql jdbc driver 2.0.11 - MySql 3.22.32로 구성되어 있으며 한글입력 및 조회시 두가지 방법이 가능합니다.
1. 인코딩 변환 미실시
권장되는 방법입니다. DB입력 및 쿼리시 인코딩 변환을 실시하지 않아 프로그램 작성이 간편하며 인코딩 변환에 따른 문자셋의 손실이 없습니다. 굳이 단점을 들자면 코드들이 인코딩 변환을 실시하지 않는 관계로 차후 호스팅 업체 변경시 해당 환경에 맞는 코드 수정이 필요하게 될 가능성도 다소 있습니다.
※ 적용방법
jsp선언부에서 charset=euc-kr을 사용하지 않습니다.
contentType="text/html" 만을 사용합니다.
2. 인코딩 변환 실시
비교적 서버환경의 사소한 변화에 강해 호스팅업체를 옮기더라도 코드수정량이 적을 수 있으나 단점으로는 인코딩 변환에 따라 DB입력전후 변환을 위한 코드량이 늘어나고 변환에 따른 일부 한글 문자셋의 손실이 있습니다.
※ 적용방법
DB입력및 조회시 인코딩 변환을 실시하며
크게 세가지 방법이 가능합니니다.
|
- DB입력시
|
:
|
"EUC-KR"
|
-->
|
"8859_1"
|
|
- DB에서 조회시
|
:
|
"8859_1"
|
-->
|
"EUC-KR"
|
2-1. 직접 바이트단위로 인코딩을 변환합니다.
- DB 입력시
// dbVar : DB에 입력할 변수명, reqVar : Request로부터 받은 변수명
String dbVar = new String(reqVar.getBytes("EUC-KR"), "8859_1");
// db 입력실시
- DB로부터 조회시
// db 조회실시
// dbVar : DB에서 조회한 변수명, disVar : 페이지에 표시할 변수명
String disVar = new String(dbVar.getBytes("8859_1"), "EUC-KR");
2-2. 각 페이지에 메소드를 선언후 이 메소드를 이용하여 인코딩을 변환합니다.
- 페이지 상단부에 메소드 선언
// Encoding변환 : "EUC-KR" --> "8859_1"
public String convertKor(String str) throws UnsupportedEncodingException{
return new String(str.getBytes("EUC-KR"), "8859_1");
}
// Encoding변환 : "8859_1" --> "EUC-KR"
public String convertEng(String str) throws UnsupportedEncodingException{
return new String(str.getBytes("8859_1"), "EUC-KR");
}
- DB 입력시
// dbVar : DB에 입력할 변수명, reqVar : Request로부터 받은 변수명
String dbVar = convertKor(reqVar);
// db 입력실시
- DB 로부터 조회시
// db 조회실시
// dbVar : DB에서 조회한 변수명, disVar : 페이지에 표시할 변수명
String disVar = convertEng(dbVar);
3-3. 컨버팅하는 메소드를 포함하는 클래스를 사용합니다.
- 아래 소스를 다운로드 받아 zip파일을 푼후 /WEB-INF/classes/에 위치후 컴파일합니다.
- javac Converter.java [패키지 적용시 javac -d . Converter.java]
다운로드 API보기
- jsp 페이지 선언부에서 Converter를 import합니다.
import="Converter"
- 해당 소스내에서 Convert의 객체를 생성하여 인코딩 변환을 실시합니다.
Converter cv = new Converter();
dbVar = cv.convertKor(reqVar); //DB입력시
disVar = cv.convertEng(dbVar); //DB쿼리시
|
|
|
| |
PHP, CGI 게시판은 훌륭한 공개소스들이
많이 제공되고 있습니다.
설치시는 매뉴얼에 따라 특히 권한 설정등에 주의하여 설치하시면 되겠습니다.
미래와 사람들에서 제공되는 서버에는 현재 CGI게시판으로는 We-board를
PHP게시판으로는 제로보드가 테스트 계정에 설치되어 있습니다.
대부분의 공개소스들이 설치가 간편합니다.
CGI게시판 --> We board
설치결과 보기
PHP게시판 --> 제로보드 설치결과 보기
|
|
|
12.
jsp파일을 변경했는데 반영이 왜 안돼죠? |
|
|
| |
jsp
사용 고객님들중에 jsp파일을 변경했는데 즉시 반영이 안된다는 문의가 있습니다.
이때 다음의 한가지를 점검해 보시기 바랍니다.
jsp는 include로 페이지를 계층적으로 설계할
수 있고 이때 다음의 두가지 방법을 쓸 수 있습니다.
물론 1과 2는 여러가지 차이점이 많이 있지만
근본적인 차이점은 1은 인클루드된 파일이 반드시 jsp일 필요는 없으며
인클루드한 jsp만 서블릿으로 변환된다는 것이고 2는 인클루드된 파일도
별도의 서블릿으로 변환된다는 것입니다.
그리고 인클루드된 파일의 경우 변경시 1의 경우는 반드시 인클루드한 파일도
변경을 해서 다시저장하셔야 하위 페이지의 변경사항이 반영이 됩니다.
2의 경우는 인클루드된 파일만 변경하셔도
즉시 변경사항이 반영이 됩니다.
|
|
|
| |
jsp 사이트들은 환경설정에 특히 민감합니다.
다음을 참고하셔서 이전가능성 여부 판단 및 이전작업에 참고하시기 바랍니다.
1) 웹서버 및 jsp 엔진 그리고 데이타베이스의 종류 및 버전
미래와사람들은 기본적으로 아파치-톰캣(3.3.1)-MySQL(3.23.51)을 사용합니다. 이중 특히 엔진의 종류가 톰캣, 레진, Apache JServ 등 다양하여 다른 엔진을 사용하시던 경우 마운트, 인클루드 선언시의 charset선언여부등의 여러가지 세부적으로 다른 측면들이 있으므로 기존 사용하시던 엔진의 종류가 상이할 경우 이전시 예기치 않은 문제 및 작업소요가 있을 수 있습니다.
2) 인코딩 변환 방식
미래와사람들 인코딩 변환방식은 두가지가 제공되고 있습니다. 인코딩 변환을 미실시하는 방법(jsp선언자부분에 charset=euc-kr을 제외)과 euk-kr과 8859_1 간에 인코딩 변환을 실시하는 방법의 두가지가 제공되고 있습니다. 보다 상세한 내용은 상기의 "jsp한글사용방법"을 참조하실 수 있습니다. 이러한 인코딩 변환방식을 기존사이트의 소스에 적용이 수월한가를 검토해 보실 필요가 있습니다. 인코딩 변환이 공통클래스로 구현되어 있거나 jsp메소드로 구현되어 있을 경우 몇부분의 수정으로 이전이 완료될 수 있지만 소스에서 매번 변환하고 있을 경우 이부분의 소스수정량이 많아질 수 있습니다.
3) 파일 핸들링시의 절대경로
파일핸들링(로그파일이나 파일 DB등)을 사용하고 있을 경우 이전 계정에서의 파일 경로와 미래와사람들 신규계정에서의 경로를 맞추어 주시는 수정이 필요하게 됩니다.
4) 데이타베이스연결방식
데이타베이스 연결시 인코딩 설정이 포함되어 있는 경우 상기 2번의 인코딩 변환 표준제공이 적용되지 않습니다. 데이타베이스 연결방식을 표준방식(상기의 jdbc드라이버사용)을 사용하여야 하며 이부분에 대한 기존 소스 수정량 판단이 필요합니다.
☞ 상기의 내용은 미래와사람들에서 타 호스팅으로 이전시에도 역으로 참조하실 수 있습니다.
미래와사람들은 고객님의 계정 사용 편의를 위하여 최대한의 노력을 하고 있습니다. 하지만 고객님의 상황에 맞는 타 호스팅으로 이전하시고자 할 시에도 필요하신 조력을 아끼지 않고 있으며 상기의 내용은 역으로 미래와사람들 계정사용중 타 사이트로 이전코자 하시는 jsp사이트에도 역으로 적용이 가능합니다.
|
|
|
| |
서버이전은 비전문가가 입장에서 집을 이사하는 것만큼이나 복잡한 과정들이 많이 내포되어 있습니다. 이전중에 많이 부딪히게 되는 과정들 및 이에 대한 방법들을 참조하여 안전하고 정확한 이전이 되도록 참고하시기 바랍니다. 이는 타사에서 당사로 계정을 이전하시는 경우 혹은 당사를 떠나 타사로 계정을 이전하시는 경우 공히 해당됩니다.
1) 계정이전의 전체적인 과정 (운용중인 사이트가 있는 경우)
다른 곳에서 운용중인 사이트를 이전하는 경우 각별한 주의가 필요합니다. 특히 사이트이전을 중단없이 실시하려는 경우 네임서버 변경등에 특별히 주의해야 합니다. 가령 www.abc.com을 현재 다른 곳에서 운용중이고 이를 당사의 계정으로 이전하려는 경우 다음과 같은 절차를 밟아야 합니다.
- 첫째, 미래와사람들에 계정을 신청합니다. 신청시 회원가입후 "웹호스팅 >> 신청하기" 부분에서 보유도메인으로 신청하는 절차를 밟습니다.
- 둘째, 계정이전을 실시합니다. 계정이전은 "소스이전"과 "데이타베이스 이전" 및 각종 "소스 수정"과 "퍼미션조정" 등을 포함합니다. 보다 상세한 사항은 아래 2번의 계정이전을 참조하시기 바랍니다.
- 세째, 계정이전 완료후 각종 테스트를 실시하여 계정이전이 완료되었다는 판단이 들면 네임서버 변경을 실시합니다. 네임서버 변경에 대한 보다 상세한 내용은 아래의 3번 네임서버의 변경을 참조합니다. 네임서버 변경이 완전히 반영되는데에는 국제도메인의 경우 약 이틀 국내도메인의 경우 12시간에서 약 하루 정도 소요되므로 해당 기간동안에는 지역에 따라 기존의 호스팅과 신규호스팅 접속이 번갈아 나타날 수 있습니다. 이기간동안 데이타베이스가 이원화될 수 있으므로(가령 네임서버 변경직후 사이트 방문자가 기존호스팅으로 접속하여 게시판에 글을 남겼는데 네임서버가 변경이 완료된후 신규호스팅에 있는 사이트에 이 글이 남아 있지 않은 경우) 이원화되어서는 안되는 중요 데이타들을 관리할 경우 즉시 가용한 미래와사람들 2차 도메인 등을 이용하여 기존 호스팅쪽에서 포워딩을 실시해야 합니다.
2) 계정이전
2.1) 소스이전
소스이전은 말 그대로 기존의 호스팅 계정에 있던 사이트 소스를 신규계정으로 이전하는 절차를 말합니다. 소스이전시 기존의 계정의 FTP를 이용하여 소스를 다운로드 받은후 신규계정에 업로드하는 절차를 밟게 됩니다. 이때 유의할 사항으로는 다음과 같은 점들이 있습니다.
- 기존계정의 텔넷 혹은 ssh 이용가능여부
텔넷 혹은 ssh가 이용 가능하다면 사이트 종류에 따라 이전이 비교적 수월해질 수 있습니다. 기존계정쪽에서 tar압축을 실시하여 이를 다운로드 받은후 신규계정에 업로드후 압축을 해제합니다. 다음과 같습니다.
기존계정에서 : tar -cvfz backup.tar.gz public_html [압축]
신규계정에서 : tar -xvzf backup.tar.gz [압축해제]
텔넷 혹은 ssh를 이용시의 장점으로는 단일 파일로서 다운로드 및 업로드가 빠르고 기존계정에서의 파일 퍼미션들이 대부분 그대로 보존됨으로써 업로드 프로그램 및 CGI프로그램들의 퍼미션 조정이 최소화 될 수 있습니다.
단점으로서는 텔넷 및 ssh가 제공되지 않는 호스팅이 많이 있고 압축 및 해제를 위한 별도의 여유공간이 필요하다는 점입니다. 가령 계정용량 300M의 Economy형을 사용하고 계신 경우 압축화일이 200M 정도 차지할 경우 이를 해제하는데에는 약 2~300M 정도의 추가적인 여유공간이 필요하며 이를 위해서 별도의 하드용량을 추가신청하는 것은 쉽지 않은 일입니다. 이경우 당사에 요청해 주시면 초기에 한하여 임시로 사용가능한 하드쿼터를 제공해 드리며 원활하게 압축을 해제할 수 있습니다.
만약 텔넷 이용이 불가능하다면 FTP로 다운로드 받은후 업로드를 실시해야 합니다.
2.2) 데이타베이스이전
사이트가 단순한 HTML만으로 이루어지거나 크레이지 보드와 같이 파일 DB를 사용하는 경우는 별도의 데이타베이스 이전 및 사용 필요성이 없습니다. 하지만 데이타베이스를 사용하는 대부분의 프로그램이전이 포함된 경우 기존 사용 데이타베이스를 이전해야 하며 데이타베이스 이전은 단순하게 FTP로부터 다운로드 받고 업로드하는 절차로 이루어지지는 않습니다.
데이타베이스 이전은 기존 호스팅으로부터 데이타베이스를 스크립트 형태로 백업받은후(Export절차) 백업받은 스크립트 파일을 신규계정에 업로드하여 이를 데이타베이스에 입력하는절차(Import절차)를 거치게 됩니다. 백업 및 데이타베이스 입력절차는 아래와 같습니다.
기존의 호스팅으로부터 데이타베이스를 백업하는 과정은 다음과 같습니다.
- 텔넷 혹은 ssh를 통하여 로그인합니다.
- mysqldump -u 데이타베이스ID -p 데이타베이스명 > backup.sql 를 실행한후 패스워드를 입력합니다. 스크립트로 백업이 정상적으로 진행되면 에러메시지가 나타나지 않습니다.
- 백업한 backup.sql을 다운로드 받습니다.
백업받은 스크립트파일을 신규계정에 업로드하여 데이타베이스에 입력하는 과정은 다음과 같습니다.
- ssh를 통하여 로그인합니다.
- mysql -u 데이타베이스 ID -p 데이타베이스명 < backup.sql 를 실행한후 패스워드를 입력합니다. 입력이 정상적으로 진행되면 에러메시지가 나타나지 않습니다.
2.3) 소스수정
소스이전과 데이타베이스 이전이 정상적으로 진행되어도 게시판과 같은 데이타베이스를 사용하는 프로그램은 정상적으로 작동하지 않을 수 있습니다. 이는 기존 호스팅의 데이타베이스 접속정보와 신규호스팅에서 세팅된 데이타베이스정보가 상이할 경우에 나타날 수 있습니다.
미래와사람들에서는 신규 호스팅 신청시 사용 데이타베이스 명 등을 입력하여 기존호스팅환경과 최대한 맞추어 소스 이전을 최소화하도록 해 드리나 부득이 변경이 발생하는 부분이 있습니다. 크게 아래와 같은 부분에서 발생할 수 있습니다.
- 계정명 및 절대경로 : 미래와사람들에서 제공하는 절대경로는 /home/계정명/public_html/하위디렉토리 이며 절대경로의 상이는 업로드 프로그램 등에서 컨프수정을 필요로 할 수 있습니다.
- 데이타베이스 접속정보(접속호스트) : 미래와사람들에서는 localhost를 사용하며 DB서버가 분리된 호스팅에서는 호스트가 xx.xxhost.co.kr 등으로 제공되는 경우가 있습니다.
- 데이타베이스명, 데이타베이스 ID, 데이타베이스 패스워드 : 데이타베이스 접속정보 등은 제로보드 등의 config.php등에서와 같은 컨프파일의 수정을 필요로 합니다.
2.4) 퍼미션 및 소유권과 관련된 문제
이전시 CGI의 퍼미션 및 업로드 파일 등의 소유권 및 퍼미션 점검이 필요합니다. 이는 개별 프로그램 배포 사이트 등을 참조합니다.
가령 제로보드 등은 이전후 config.php의 수정 및 업로드된 디렉토리의 퍼미션 조정이 필요합니다. icon, data 디렉토리 등의 퍼미션을 조정합니다.
또한 CGI프로그램의 경우 실행권한을 부여해야 하며 705 혹은 755 정도의 퍼미션 조정이 필요합니다. 각각의 개별적인 프로그램의 배포처에서 이전가이드 혹은 팁공유 등을 통하여 확인할 수 있습니다.
2.5) JSP사이트의 이전
JSP사이트의 이전은 상기의 내용에 더하여 본 페이지에서 제공되고 있는 JSP이전가이드를 참조합니다.
3) 네임서버의 변경
상기의 모든 이전이 완료되어 신규호스팅에 똑같은 계정이 세팅되면 도메인을 신청한 업체의 홈페이지에 가셔서 네임서버변경을 실시합니다. 통상적으로 정보/네임서버 변경 항목 등에서 네임서버를 변경할 수 있도록 사이트가 구성되어 있으며 도메인 소유주 혹은 도메인 관리자가 변경해야 합니다. 변경후 기존의 호스팅쪽으로 가던 요청이 신규호스팅서버로 돌아오는데 국제도메인은 약 이틀 국내도메인은 약 12시간에서 하루정도 소요되므로 이점에 대한 감안이 필요합니다.
- 메일데이타의 유실 및 데이타베이스의 이원화 문제
네임서버 변경후 기존의 호스팅쪽으로 가던 요청이 신규호스팅쪽으로 돌아오는 동안에 메일 및 데이타베이스에 관련되어 몇가지 문제가 발생할 수 있습니다. 네임서버 변경후 기존호스팅에서 신규호스팅으로 요청이 돌아오는 과정은 각 ISP사의 네임서버 캐쉬가 업데이트되는 과정이므로 지역에 따라 신,구 서버로의 접속중 어느쪽도 가능할 수 있는 상황이므로 발송자는 예전 호스팅의 메일서버로 메일이 접수된 상황에서 사이트 관리자는 신규호스팅쪽에서 메일을 받아가게 되므로 메일이 분실된 것과 같은 효과를 느끼게 됩니다. 이경우 네임서버가 완전히 변경된후에도 며칠간 기존호스팅의 메일 계정에서 메일을 받아야 합니다.
또한 데이타베이스도 이원화 될 수 있습니다. 가령 기존의 계정으로 접속한 방문자가 게시판에 글을 남긴후 네임서버가 완전히 돌아온후 신규계정에 있는 사이트를 보게 되면 글이 없어지거나 혹은 쇼핑몰과 같은 경우 주문데이타가 유실된 것과 같은 효과를 볼 수 있습니다.
이러한 경우를 방지하기 위한 조치로는 기존의 호스팅 계정의 Index페이지에 접속했을때 신규호스팅쪽으로 포워딩 할 수 있는 포워딩 소스를 운영하여 기존호스팅쪽으로 들어온 방문자를 신규호스팅 서버쪽으로 유도합니다.
이때 본 도메인의 네임서버변경과 관계없이 즉시 사용가능한 도메인이 필요하며 미래와사람들에 xxx.humanfuture.co.kr과 같은 2차도메인을 요청하여 임시주소로 사용하실 수 있습니다.
|
)
)
)
)
)
)
)
)
)
)
)
