준서아빠가 생각하는 행복한 UX 이야기

웹서버 관리 자동화에 대한 단상 - 명령 프롬프트, 파워쉘 스크립팅과 WMI & MWA

2009-10-29T00:31:11Z

안녕하세요. IISKOREA 팀블로그의 김대우 입니다. 이번에 같이 고민해 보고 싶은 내용은 지난번의 포스팅에 이어서 두번째, 바로 “웹서버 관리 작업 자동화”에 대한 내용으로 포스팅을 풀어 보려고 합니다.
지난 포스트를 통해 IIS7의 다양한 설치/구성/관리/배포 기능 및 도구 소개 - 관리 및 배포 툴에 대해서 이야기를 드렸는데요. 이번에는 관리 자동화 툴에 대해 초점을 맞춰 단상을 정리해 보려고 합니다.

IIS는 이러한 관리작업 자동화를 위해 여러가지 도구들을 제공하는데요. – 당연히 IIS 관리자는 GUI툴이니 자동화 도구라고 할 수 없겠죠?(설마, 현업에서 말하는 인간 자동화???) ^_^;;;

이렇게 IIS의 구성 정보를 담고있는 XML 파일을 수정하는 방법이지요. 특히, 자동화를 위해서는 파워쉘과 명령 프롬프트의 AppCmd를 이용하는 것이 하나의 방법이 되실 겁니다.

IIS의 자동화를 위해서는 크게 세가지를 보시면 될 것 같습니다.
(1) 파워쉘(Power Shell)
(2) AppCmd 명령 프롬프트 처리
(3) WMI(Windows Management Instrumentation)와 MWA(Microsoft.Web.Administration) API

GUI 관리 툴일 경우 여러 단계를 거쳐야 하는 작업들을 이 자동화 툴들을 이용하면 스크립트화 시켜주기 때문에 유용한데요. 조금만 더 알아 보도록 하면

(1) 파워쉘 – IIS 7용 파워쉘 스냅인을 이용 가능합니다.

- 강력하고 심플함 : 매우 복잡한 관리 작업들을 키워드 기반 프로그래밍 명령어들로 자동화 시킬 수 있음
- 오브젝트 기반 : 여러 오브젝트들을 호출해 스크립트에서 작업 가능
- 심플하고 강력한 명령줄 기반 인터페이스 : 복잡한 스크립트를 명령줄 기반으로 제작해 안전하게 테스트도 가능
- 시스템 통합 : .NET Framework나 WMI 확장기능, 레지스트리 등에 대한 호출 및 처리가 가능
- 안전 최우선 작업 가능 : 인승서 기반의 사인된(Signed) 스크립트를 지원해 안전하게 여러 작업을 제한 가능함

참고자료 :
Managing IIS with the IIS 7.0 PowerShell Snap-in
Windows PowerShell Snap-In

(2) AppCmd 명령 프롬프트

이 AppCmd가 생소한 분들도 계실 것 같은데요. 이런 형태의 명령 프롬프트에서 수행하는 작업으로 웹사이트 제작, 응용프로그램 풀 바인딩 등의 작업을 손쉽게 처리 가능합니다. 이녀석은 어떤 장점이 있을까요?
- 웹사이트, 웹 어플리케이션, 응용프로그램 풀, 가상 디렉토리를 생성하고 구성할 수 있음
- 웹사이트 시작, 중지 명령을 수행 가능하며, 응용프로그램풀을 리사이클링 시킬 수 있음
- 수행중인 작업자 프로세스에 대한 리스트와 현재 실행중인 요청에 대해서 조회 가능
- IIS와 ASP.NET 구성 정보에 대해서 조회, 출력, 내보내기(Export), 가져오기(Import)를 수행 가능

참고자료 :
AppCmd.exe 소개
ABC's of Appcmd (command line administration in IIS7)

AppCmd도 이렇게 여러가지 명령줄 기반 자동화 작업을 수행이 가능합니다. 그렇다면 갑자기 드는 생각인데요. 파워쉘과 AppCmd의 차이는 어떻게 설명이 가능할까요?
- 파워쉘은 오브젝트 기반으로 더욱 유연하고 복잡한 관리 작업들을 수행 가능합니다. 또한 파워쉘은 .NET Framework나 WMI 확장 API를 접근 가능하고 높은 보안성을 요구하는 복잡한 스크립트 작업을 실행 가능합니다.
- AppCmd는 파워쉘에 비하면 심플하고, IIS 관리를 위한 기능들에 초점을 맞춰 실행이 가능합니다. 바꿔말하면, 파워쉘과 같은 강력하고 복잡합 스크립트 기능은 이용이 불가능합니다.

이렇게 두가지, 관리자 분들이 선호하시는 자동화 관리 툴에 대해서 알아 보았습니다. 개인적인 소견으로 파워쉘이나 AppCmd는 개별 서버 기반에서 작업하거나, 관리하는 서버의 수가 5~10대 미만이라면 이용 가능하겠으나, 수십 수백대의 서버를 유지 관리해야 하는 호스팅회사와 같은 경우에는 관리 작업이 쉽지 않을 겁니다. 이럴때 이용하는것이 바로 MWA와 WMI를 이용해 직업 각 회사에 맞는 작업을 처리 가능한 관리 프로그램을 제작하는 것이지요. 왜 MWA와 WMI가 필요한지는 감 잡으셨는지요? 그렇다면, MWA와 WMI와 같은 관리 프로그램 제작을 위한 API들에 대해서 알아 보도록 할까요?

(3) WMI(Windows Management Instrumentation)와 MWA(Microsoft.Web.Administration) API
먼저 WMI를 소개해 드리고 이어서 MWA를 이야기 드리려고 합니다.
WMI로 수행할 수 있는 작업
- 웹사이트 생성
- 전체 웹사이트 조회
- 웹사이트 중지, 시작
- 웹사이트 삭제
- 웹사이트 인스턴스 및 어플리케이션 인스턴스 관리
- 어플리케이션 도메인 관리 및 작업자 프로세스 관리
즉, IIS와 관련된 다양한 작업들을 이 WMI를 이용해 모두 프로그래밍적으로 자동화 처리가 가능합니다.
참고자료 : Managing Applications and Application Pools on IIS 7.0 with WMI

그렇다면 MWA는 어떨까요?
MWA를 보시기 전에 - IIS는 XML 구성 파일(applicationHost.config 파일과 web.config 파일)에 대해서 개발사가 자신의 커스텀 구성 섹션을 이용 가능하도록 허용하고 있습니다. 개발사는 이 영역에 기술된 구성 정보를 프로그래밍적으로 가져와 처리할 필요가 있을 수 있는데요, 이때 사용 가능한것이 바로 MWA API입니다.
참고자료 : Overview of MWA and MWM for IIS 7.0
참고로, 파워쉘을 이용해 WMI나 MWA 오브젝트를 호출해 속성 등을 불러와 파워쉘 스크립트로 처리하는 작업도 가능합니다.

이렇게 간단히, 웹서버 관리 자동화에 대한 내용을 정리해 보았습니다. 개인적으로는 좀더 욕심이 있어서, 호스팅회사가 처리해야할 자동화 작업 목록이나 기술 명세가 있다면 한번 마음 맞는 분들끼리 관리 툴을 오픈소스로 만들어 보는 것도 하나의 좋은 시도가 아닐까 생각됩니다. ^_^

감사합니다.

참고자료 : Provisioning Options in IIS 7.0

IIS7.5 Application Warm-Up

2009-10-27T07:42:49Z

안녕하세요, IISKOREA 팀블로그의 송원석 입니다.

윈도우 서버 2008 R2, 그리고 윈도우 7 에서 제공되는 IIS 7.5에 흥미로운 기능이 한 가지 추가되어 소식을 전합니다. 바로 Application Warm-Up 이라는 기능인데요, 현재 Beta 상태로 관련 모듈을 다운로드 받아 설치할 수 있습니다. 과거 URL Rewrite 모듈 역시도 별도의 다운로드 모듈 형태로 제공되다가 정식으로 포함된 사례를 감안해 볼 때, 이번 Application Warm-Up 모듈도 같은 수순을 밟게 될 것으로 예상됩니다. 보다 정확하고 상세한 내용은 다음의 문서를 참고하시면 될 것 같습니다.

Getting Started with the IIS 7.5 Application Warm-Up Module

이 문서에서는 Applcation Warm-Up 에 대한 개요를 보여주고 있습니다만, 아쉽게도 대부분의 진행이 파워쉘를 기반으로 하고 있어서, 개발자분이시거나 평소 파워쉘에 대해 관심을 갖고 계셨던 분이 아니시라면 조금 난해할 수도 있을 것 같습니다. (나중에 저희가 캡춰로 도배된 따라하기 문서를 한 번 만들어 보는 것고 좋을 것 같습니다.)

그리고, 실제 모듈은 다음 경로에서 다운로드 받으실 수 있습니다. 아직 Beta 버전이며, IIS 7.0에서도 동작하는지는 확인해보지 못했습니다.

Application Warm-Up

간단히 그 내용을 살펴보자면 이렇습니다.

일반적으로, IIS 에 배포된 웹 응용 프로그램은 사용자의 요청에 의해 실행이 됩니다. 즉, 평소에는 메모리에 올라와 있지 않은 상태인 것이죠. 그러다가, 임의의 사용자가 처음으로 해당 웹 응용 프로그램을 요청하는 순간, 초기화가 수행되고 비로소 메모리에 올라와서 작업을 수행하게 됩니다. 일반적으로 이 초기화 과정 중에 이루어지는 작업에는 대략 다음과 같은 작업들이 있을 겁니다.

먼저, 당연히 ASP.NET 프로그램의 JIT 컴파일이 이루어져야 하겠죠.
그리고, 필요하다면 데이터베이스 연결도 얻어야만 합니다. (한 번 생성해 놓으면 커넥션 풀을 이용할 수 있으므로 첫 번째 요청과 두 번째 요청에서의 속도에는 확실히 차이가 존재합니다.)
일부 코드 Set 을 미리 로드해 놓는 웹 응용 프로그램들도 존재합니다. 이를테면 미리 캐시를 해놓는 거죠. (지금 제가 참여중인 프로젝트가 바로 그렇습니다.)
필요한 HTTP 모듈이나 핸들러도 로드되어야 하구요. (사용자 정의 모듈이나 핸들러 뿐만 아니라, IIS 7.x 자체의 모듈들도 모두 HTTP 모듈이나 핸들러라는 점을 유의하십시오.)
그 밖에 기타 필요한 작업들이 처리되겠죠.

그런데, 만약 해당 응용 프로그램이 초기화에 많은 비용이 소모되는, 상대적으로 무거운 축에 속한다면, 운나쁘게도 가장 먼저 웹 응용 프로그램을 요청한 사용자는 제법 긴 시간동안 대기를 해야하게 될 것입니다.바로 이런 문제점을 해결하기 위해 제공되는 기능이 Application Warm-Up 입니다. 흔히 우리는 운동을 하기 전에 워밍업을 한다는 표현을 쓰곤 합니다. 마치 이처럼 웹 응용 프로그램도 워밍업을 해두는 것이죠. 그리고 요청이 들어왔을 때 신속하게 서비스를 제공한다는 개념입니다.

일반적인 웹 사이트의 경우에는 이 기능의 장점이 확연하게 느껴지지 않을 수도 있을 것입니다. 그러나, 클라우드 서비스를 제공해야 되는 시스템이라던지, n 티어 시스템의 비즈니스 로직 계층의 경우라면 그 응답성 향상이 눈에 띌 정도가 되지 않을까 생각해봅니다.

그리고, Application Warm-Up 기능을 설정할 수 있는 단위는 웹 응용 프로그램이라고 하는데요, 사실 이건 당연한 얘기일 것입니다. 왜냐하면 웹 응용 프로그램이 바로 작업자 프로세스의 단위이기 때문이죠.

보다, 자세한 내용은 후에 기회가 닿으면 한 번 다시 말씀드리도록 하겠습니다.

감사합니다.
P.S 그리고 보니 이 포스트가 제 인생 최초의 포스트네요.

IIS의 다양한 구성/관리/배포기능 소개

2009-10-27T07:41:34Z

안녕하세요. IISKOREA 팀블로그의 김대우 입니다. 이번에 소개해 드릴 내용은 어플리케이션 개발자 / 관리자 분들이라면 모두가 고민하는 웹 어플리케이션의 구성/관리/배포에 대한 내용입니다.

단순히, 웹사이트 설치나 웹사이트 이전, 백업 하는 정도라고 생각하기 쉽습니다만, 웹사이트 및 응용프로그램들이 가지는 다양한 종속성(Dependency)등에 대한 고려와 시스템 / 웹사이트에 대한 설정까지 다양한 환경이 정확히 생성/관리/배포 되어야 하기 때문에 관리 작업에서 가장 어렵고 시간이 많이 소요되는 힘든 과정이 바로 이 구성/관리/배포가 아닐까 생각합니다.

또한, 한 두대의 웹서버를 관리하시는 분들부터, 5~10대의 서버를 관리해야 하는 경우, 또는 수백대의 웹서버를 자동화 기능들을 통해 관리해야 하는 호스팅사까지 다양한 환경에 맞는 스크립트나 배포 도구, 또는 필요할 경우 배포나 유지관리를 위한 툴을 직접 제작해야 하는 경우까지, 다양한 환경에 맞는 기능을 선택하는 것도 필요하실 겁니다. 이런 비지니스 구조, 환경에 맞는 툴들이나 방법은 어떻게 선택해야 할까요?

예를 들어, 한 서버에서 대략 300개 정도의 운영 중인 웹사이트에 하드웨어 적인 장애가 발생해 다른 시스템으로 이전해야 하는 상황이 발생하는 (웹호스팅) Shared Hosting 환경이라면 어떨까요? 더더욱 자동화된 배포나 이전, 백업 등에 대해서 고민하시게 될겁니다.

이 복잡한 작업들을 어떻게 쉽고 빠르게 해결 가능할까요?
IIS7은 여려 배포를 위한 훌륭한 기능들을 제공하고 있는데요. 그 배포 기능들을 차례대로 소개해 드리려고 합니다. ^_^

IIS의 다양한 배포 도구

(1) 웹 플랫폼 설치 관리자 – WPI

웹플랫폼 설치 관리자는 설치 과정을 GUI로 쉽게 구성 가능하도록 돕는 도구 입니다. 특히, Dependency가 있는 웹 어플리케이션을 자동으로 설치하거나, 관리툴, 개발도구, 다양한 확장기능들을 설명과 함께 선택이 가능하기 때문에 유용한 도구 입니다.
- 가장 손쉽고 자동화된 설치 환경 제공
- 국내&전세계의 다양한 웹 어플리케이션 기본 탑재
- 웹서버/데이터베이스서버/프레임워크/도구들을 설치 가능
- 웹 어플리케이션 설치시 종속적인 웹서버 기능이나 데이터베이스 기능들을 자동 설치
WPI 기술소개 링크 : http://www.iis.net/webpi
WPI 다운로드 : http://www.microsoft.com/web/downloads/default.aspx
웹플랫폼 설치 관리자는 단순한 배포 도구를 넘어선, 훨씬 중요한 역할을 Microsoft 웹 플랫폼 아키텍쳐와 관련해 수행하게 되는데요. 관련해서는 따로 상세하게 소개해 드릴 예정이니 도움 되시길 바랍니다.

(2) 웹 배포 도구 – Web Deployment Tool

웹 배포 도구는 웹사이트나 웹서버에 대해서 배포를 가능하게 돕는 IIS7의 확장기능(Extension)입니다. 특히, IIS6에서 IIS7으로의 마이그레이션이나 구성파일 패키징 기능을 지원하기 때문에 다양한 웹사이트 구성을 쉽게 이전이 가능한 특징이 있습니다. 여러대의 서버를 관리하는 경우라면 이 웹 배포 도구가 많은 도움이 되실 겁니다.
링크 : http://www.iis.net/extensions/WebDeploymentTool
- 패키징 기능으로 전체 웹사이트 파일, 포함된 데이터베이스, 권한 및 레지스트리정보 등을 패키지 가능
- IIS6를 IIS7으로 손쉽게 마이그레이션 가능
- 서버간 동기화(Synchronization) 가능
- IIS Manager와 연계해 이용 가능
웹 배포 도구 관련된 내용 역시 곧 포스트를 통해 상세히 전달해 드릴 예정입니다.

(3) IIS7의 파워쉘(Power Shell) 부가기능
파워쉘은 윈도우서버에 대해서 관심있는 분들은 잘 알고계시는 기능일텐데요. 윈도우 서버의 다양한 작업들을 파워쉘을 이용하면 모두 스크립트로 자동화가 가능한 것처럼, IIS7도 파워쉘을 이용해 모든 기능들을 스크립트화 시킨 후 웹사이트 생성부터 유지관리까지의 작업을 스크립트로 자동화시켜 실행 가능합니다. 다수의 웹서버를 관리하실 경우에 유용하며, 호스팅 환경 등에서도 활용 가능합니다.
- IIS7의 구성 정보들을 파워쉘 스크립트로 관리
- 웹사이트, 응용프로그램 풀, 웹응용프로그램, 가상디렉토리, 작업자 프로세스 등을 관리 가능
- 파워쉘의 다양한 스크립팅 기능으로 대규모의 복잡한 IIS 관리 기능을 처리 가능
- 파워쉘 2.0의 원격 기능을 이용해, 원격 서버를 파워쉘로 제어 가능
마찬가지로, IISKOREA 팀블로그에서 이 파워쉘을 이용한 유지 관리도 준비하고 있으니 기대해 주세요.

(4) 프로그래밍 API를 이용한 사용자 정의(Custom) 배포/관리툴 제작을 위한 기능
API를 이용한 방법은 자신이 소속된 회사에 적합한 패턴의 웹서버 생성, 관리 및 배포를 위한 프로그램을 직접 제공되는 기능을 이용해 제작 가능하게 합니다. 즉, 수백대가 넘는 호스팅사와 같은 IIS 웹서버 관리에 필요한 기능들을 이 제공되는 프로그래밍을 위한 API로 제작해 회사에 맞는 관리/배포를 위한 프로그램 직접 생성 가능하게 합니다. – 이미 나와있는 관리 솔루션들도 있지요.
WMI(Windows Management Instrument)
http://learn.iis.net/page.aspx/163/managing-applications-and-application-pools-on-iis-7-with-wmi/
Microsoft.Web.Administration
http://learn.iis.net/page.aspx/165/how-to-use-microsoftwebadministration/

자~ 이렇게 IIS는 비지니스 방식과 운용 규모 등에 맞는 다양한 관리/배포 도구를 제공하고 있습니다. 각각의 기능들에 대해서는 차후에 IISKOREA의 팀블로그를 통해 계속 소개해 드리도록 하겠습니다.
감사합니다.

PHP 삽질그만 #1 - MySQL & MSSQL DB를 GUI와 IIS7로 빠르게 개발

2009-10-20T00:39:36Z

안녕하세요, IISKOREA 팀블로그의 김대우 입니다. 이번에 소개해 드릴 내용은 살짝 도발적이기도 할 것 같은데요. 당연히 IIS와 관련된 내용이기도 합니다. 혹시, SQL서버의 쿼리 툴을-정확히는 GUI기반 툴을- 사용해본 경험이 있으신지요?

SQL2008의 GUI 관리 툴인 SQL Server Management Studio

SQL2000 시절에는 GUI 툴의 쌍두마차인, 엔터프라이즈 관리지와 쿼리 분석기가 있었지요. GUI로 편리하게 쿼리를 작성 가능하고, 데이터 조회, 프로시져 생성 등의 개발과정에 필수적인 쿼리 작성에 꼭 필요한 여러 기능들을 모두 담고 있는 유용한 녀석입니다. 특히, 조회한 결과를 그리드(표형식)로 볼 수 있고 쿼리 제작과 수정도 용이하기 때문에(vi 쓰시는 분들 말고 ^^;;) 개발 시간을 엄청나게 단축해 주는 녀석이기도 하지요. 하지만, 웹서버에 이 툴들을 설치하기도 애매한 노릇이고, DB서버마다 원격 접속하기도 쉽지 않지요. 특히, 여러 DB를 다루면서 개발과 관리를 동시에 해야 하는 PHP 개발자 분들은 시간이 많이 소요되는 작업이실 겁니다. - DB도 MySQL만 하는게 아니라 MSSQL도 같이 관리 하신다면? 가히 서버 관리 때문에 머리가 터져버릴지도…

IIS7는 PHP를 위한 최고의 개발 / 서비스 환경입니다.
IIS7은 윈도우 기반으로 Vista 및 Win7, Windows Server 2008에서도 이용 가능합니다. 즉, 주로 개발을 진행하시는 윈도우 환경에서 쉽게 구축이 가능하며, FastCGI를 통해 PHP를 아주 깔끔하게~ 지원합니다. 이런 개발용 PC에서 원격지의 SQL서버나 MySQL DB 처리, 또는 개발을 쉽게 할 수는 없을까요?

특히, PHP 개발 과정에서 주로 사용하는 + MySQL 또는 MSSQL은 DB에 접속해 개발하시기 어떤가요? – 쓸만한 GUI 쿼리 툴?
MySQL GUI 툴들 세트가 있긴 하지만 2%가 아닌 20% 넘게 부족한 느낌입니다. 또한, 한 PHP 하시는 분들께 비교적 잘 알려진 SQLyog라는 녀석이 있긴 합니다만, 유료라는게 좀~ 부담스럽습니다. 무료에 깔끔한, PHP 개발에 이용 가능한 그런 녀석은 없을까요? 있습니다. 바로, IIS 데이터베이스 관리자(Database Manager) 입니다.

IIS 데이터베이스 관리자로 MySQL과 MSSQL 웹 개발을 더욱 더 편리하게~

IIS의 기능 설치 관리를 위한 핵심 툴인 웹 플랫폼 설치 관리자를 실행 하시고, 웹플랫폼 – 웹서버 – 관리 항목에서 “데이터베이스 관리자”를 선택 가능합니다. 이어서 설치를 진행하시면 몇몇 종속성 기능들과 함께 설치가 완료됩니다.
참고 정보 : IIS Database Manager

Database Manager가 제공하는 기능
- 로컬 또는 원격지의 MSSQL, MySQL 데이터베이스를 관리 가능합니다.
- 테이블 추가, 수정, 삭제, 이름바꾸기 가능
- View 및 테이블 개체(PK, FK, 색인) 등을 관리 가능
- 테이블의 데이터를 GUI로 손쉽게 수정 가능
- 쿼리 제작 및 실행 가능
- 저장 프로시져 및 View 생성,수정,삭제 가능
- MSSQL 서버에 대해 백업과 복구 가능
- MSSQL과 MySQL을 제외한 다른 DBMS에 대해 관리 기능 확장을 위한 API 제겅(즉, 타 DB도 개발해 IIS 모듈로 추가 가능)
이렇게 흥미로운 기능들을 Database Manage가 제공합니다. 그럼, 실행하고 직접 DB에 붙어 볼까요.

Database Manager 실행
설치가 완료되면 IIS7의 관리 툴에서 Database Manager를 실행합니다.

이어서 MSSQL이나 MySQL 연결을 추가합니다.

Add connection을 클릭히고

Connection을 추가합니다. 물론, MySQL을 선택 하고 연결 정보를 입력하시면 물론 MySQL에 연결 가능합니다.

데이터를 그리드에서 조회가능하며, 다양한 작업을 수행 가능합니다.

테이블 스키마 정보도 확인 가능하며

PHP 개발 과정에서 꼭~ 필요한 쿼리 제작 및 수행도 손쉽게 처리 가능합니다.이렇게 데이터베이스를 쉽게 IIS에서 조회 가능하고, 쿼리 수행도 가능하며 원격 서버 관리 기능도 포함되기 때문에 개발하실때 유용할 것 같네요. 개인적인 생각에 MSSQL과 거의 동일한 인터페이스이기 때문에 MSSQL에 약간이라도 경험이 있다면 도움말이나 설명 없이도 슥슥~ 사용 가능하실 것 같습니다.

이렇게 간단히 IIS7의 Database Manager에 대해서 알아 보았습니다. IIS7은 PHP 개발과 배포에도 좋은 환경입니다. – 특히 관리 및 보안에 장점이…. 이런 여러 좋은 장점들에 대해서도 차근차근 풀어 보도록 하겠습니다. 감사합니다.

참고자료
IIS Database Manager
Using the IIS Database Manager
Basics of the IIS Database Manager

URL Rewrite 1.1 (URL 재작성) - (6) Rewrite Map 사용

2009-10-19T01:05:00Z

지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)

안녕하세요. IISKOREA의 김대우 입니다. 이번에 소개해 드릴 내용은 Rewrite Map에 대한 내용인데요.

간단히 말씀 드리자면, 모든 URL 변환 처리를 패턴을 이용해 프로그래밍적으로 처리 가능하다면 행복할 겁니다. 하지만, 모든 URL 처리가 이렇게 패턴에 매핑 가능한 것은 아닐겁니다. 바로 이럴 경우, URL 처리를 위한 패턴매칭 규칙(Rule)을 적용하기 어려운 여러 URL들에 대해 새로운 URL로 정의하려 할 경우에 Rewrite Map을 이용해 1:1로 매핑하는 처리를 이용하면 유용합니다. 즉, 단순 URL Rewrite Rule이 생성되는 것은 줄이면서 효율적으로 Rewrite 처리가 가능해지는 장점이 있는 것이지요. 물론 Rule의 수가 줄어들게 되니 정규표현식 처리가 줄게되고 이어서 시스템리스소도 적게 사용할 수 있을 겁니다.

Rewrite Map 제작
마찬가지로, 테스트를 위해 예전 포스트에서 작성한 심플한 article.aspx 파일을 이용해 볼께요.

<%@ Page Language="C#" %><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><title>URL Rewrite Module Test</title></head><body>      <h1>URL Rewrite Module Test Page</h1>      <table>            <tr>                  <th>Server Variable</th>                  <th>Value</th>            </tr>            <tr>                  <td>Original URL: </td>                  <td><%= Request.ServerVariables["HTTP_X_ORIGINAL_URL"] %></td>            </tr>            <tr>                  <td>Final URL: </td>                  <td><%= Request.ServerVariables["SCRIPT_NAME"] + "?" + Request.ServerVariables["QUERY_STRING"] %></td>            </tr>      </table></body></html>

테스트를 위해 http://localhost/article.aspx 링크를 접속해 보면 아래와 같은 결과를 보실 수 있을 겁니다.
(만약 안 나오신다면 ASP.NET 서비스를 설치해 주세요.)

Rewrite Map 생성
그렇다면, 본격적으로 Rewrite Map을 생성해 보겠습니다.

URL Rewrite를 선택해 주세요.

Manage rewrite map을 선택해 Rewrite Map을 생성합니다.

이렇게 이름을 “StaticRewrite”로 설정하고 “Add Mapping Entry”를 선택해 다음 Entry들을 넣습니다.

각각 값을 “/article1” 그리고 New Value를 “/article.aspx?id=1&title=some-title” 으로 지정합니다. 즉, /article1 요청이 들어오면 뒤에 나오는 URL로 rewrite 하라는 의미이지요.

Original URL	New URL
/some-title	/article.aspx?id=1&title=some-title
/post/some-title.html	/article.aspx?id=1&title=some-title

이런 형태로 값을 넣어 줍니다. 이어서 확인할 내용! 과연 이 매핑 정보는 어디에 저장될까요? 넵! 바로 web.config에 저장되게 됩니다. 어떻게? XML 형태로요.

   1: <rewrite>   2:     <rewriteMaps>   3:         <rewriteMap name="StaticRewrites" defaultValue="">   4:             <add key="/article1" value="/article.aspx?id=1&amp;title=some-title" />   5:             <add key="/some-title" value="/article.aspx?id=1&amp;title=some-title" />   6:             <add key="/post/some-title.html" value="/article.aspx?id=1&amp;title=some-title" />   7:         </rewriteMap>   8:     </rewriteMaps>   9: </rewrite>

이렇게 보시는 것처럼 web.config에 차곡차곡 저장되게 됩니다. 주의해서 보실 것은 Rewrite Rule이 아니라 rewriteMap 하위에 저장된다는 것이지요.

그렇다면, 이 Rewrite Map을 어떻게 Rewrite Rule에 매핑 시킬까요? 바로 새로운 Rule을 만들고, 그 Rule에 이 Map을 걸어 주는 형태로 완성됩니다.

”Add Rule”을 실행하고, Rule with rewrite map을 선택합니다.

이어서 Rule Action은 “Rewrite”, rewrite map은 당연히 조금 전에 위에서 생성한 “StaticRewrite”를 선택 가능합니다.

그렇다면 확인을 위해 web.config를 열어 볼까요?

   1: <rewrite>

   2:     <rewriteMaps>

   3:         <rewriteMap name="StaticRewrite">

   4:             <add key="/article1" value="/article.aspx?id=1&amp;title=some-title" />

   5:             <add key="/some-title" value="/article.aspx?id=1&amp;title=some-title" />

   6:             <add key="/post/some-title.html" value="/article.aspx?id=1&amp;title=some-title" />

   7:         </rewriteMap>

   8:     </rewriteMaps>

   9:     <rules>

  10:         <rule name="Rewrite rule1 for StaticRewrite">

  11:             <match url=".*" />

  12:             <conditions>

  13:                 <add input="{StaticRewrite:{REQUEST_URI}}" pattern="(.+)" />

  14:             </conditions>

  15:             <action type="Rewrite" url="{C:1}" appendQueryString="false" />

  16:         </rule>

  17:     </rules>

  18: </rewrite>

10번 라인부터 16번 라인까지 보시면 Rewrite Map을 처리하는 Rule을 확인 가능하지요.
11번 라인의 “<match url=".*" />”은 모든 인입되는 URL에 대해서 동작한다는 의미 입니다.
13번 라인의 내용은 StaticRewrite Map에서 리턴되는 값이 빈 문자열이 아니라는 조건 처리 입니다.
15번 라인의 Action은 이 Rewrite Map에서 나온 결과값으로 URL을 Rewrite하는 동작을 수행하라는 의미 입니다.

그렇다면, 우리가 만든 Rewrite Map이 잘 동작하는지 확인을 위해 테스트를 해 볼까요.
http://localhost/article1
http://localhost/some-title
http://localhost/post/some-title.html

위의 테스트 작업을 수행하면 아래처럼 결과가 잘 나오는 것을 확인 가능할 것입니다.

그렇다면, “Redirect”는 어떻게 처리 가능할까요? Rewrite와 같습니다.

Rewrite Map을 Rule에 매핑하던 화면 기억 나시는지요? 여기에서 Rewrite 대신 Redirect를 선택하시면 됩니다.

마침 - Rewrite Map을 왜 사용하는가?
모든 URL 처리가 패턴 규칙으로 매핑 가능하지는 않습니다. 이렇게, URL 처리를 위한 패턴매칭 규칙(Rule)을 적용하기 어려운 여러 URL들에 대해 새로운 URL로 여럿 정의하려 할 경우에 Rewrite Map을 이용해 1:1로 매핑하는 처리를 이용하면 유용합니다. 단순 URL Rewrite Rule이 생성되는 것은 줄이면서 효율적으로 Rewrite 처리가 가능해지는 장점이 있는 것이지요. 물론 단순 Rule들을 나열하는 것보다 부하를 줄일 수도 있다고 합니다.

이렇게 해서 전반적인 URL Rewrite 기능에 대해 알아 보았습니다. URL Rewrite만 해도 유용한 Fancy URL 제작 기능부터 보안 기능 등 다양한 내용이 포함되어 있는 것 같습니다. 이 외에도 IIS에 대한 수많은 유용한 기능들이 있는데요, IISKOREA 팀분들과 차근차근 좋은 내용으로 풀어 나가 보도록 하겠습니다. 감사합니다.

지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)

참고자료
서버주무르기 - IIS 7, URL Rewrite Module (URL 재작성 모듈)
Using Rewrite Maps in URL Rewrite Module
Using URL Rewrite Module

URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)

2009-10-16T08:25:14Z

지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite

안녕하세요. 김대우 입니다. 이번에 소개해 드릴 내용은 아파치(Apache) 웹서버에서 이용하는 Rewrite인 mod_rewrite의 규칙들을 그대로 가져와 IIS에서 사용하는 방안에 대해서 소개해 드리려고 합니다.

간단히, 국내에서 많이 사용되는 PHP 어플리케이션인 텍스트큐브(Textcube)나 XpressEngine(제로보드XE)를 통해 말씀 드리자면, IIS의 URL Rewrite에 맞는 Rule을 제공하거나, .htaccess 파일에 존재하는 Rule을 그대로 가져와 URL Rewrite에서 이용 가능합니다.

XpresssEngine(제로보드XE)에서 URL Rewrite를 사용하는 방법- Import만 하면 순식간에 끝납니다!

XpressEngine의 경우 Rewrite를 이용하기 위한 설치 옵션이 있습니다. IIS에서 설치하실 경우에도 체크 하세요.

설치된 URL Rewrite를 실행하고 규칙 가져오기(Rule Import)를 진행합니다.

Import Rules을 선택하고

가져올 파일은 당연히 .htaccess의 파일을 선택합니다.

가져온 파일에서 이렇게 Import를 수행하고 적용하시면 끝~ 아파치 웹서버의 mod_rewrite rule 가져오기~ 참 쉽죠잉~

텍스트큐브(Textcube)에서 URL Rewrite를 적용하는 방법 – 설치시 옵션이 기본 제공됩니다.

텍스트큐브 설치 화면에서 이렇게 웹서버가 체크되면 IIS를 자동으로 인식해 IIS Rewrite Module 설치 가능 여부를 알려 줍니다. 텍스트큐브 조아요~

이렇게, IIS7을 선택해 주시고 다음을 누르시면 됩니다. 참고로, IIS6 등에서 이용 하실 경우에는 다른 URL Rewrite도 이용 가능하시지만, 권장해 드리고 싶지 않습니다.

지금 보고 계신 이 IISKOREA 팀블로그도 윈도우즈서버2008 웹에디션 + IIS7 으로 운영되고 있는데요. 텍스트 큐브 잘되고 좋네요.

이렇게 아파치(Apache) 웹서버에서 이용되는 mod_rewrite 규칙을 IIS의 URL Rewrite로 가져오는(Import)하는 방법에 대해서 알아 보았습니다. IIS의 URL Rewrite의 기능들을 이제 거의 알아보았는데요, 국내의 여러 멋진 오픈소스들과 함께 앞으로 유용하게 잘 사용되면 좋겠습니다.

지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite

URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite

2009-10-15T07:04:55Z

지난 포스트 링크

URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite

안녕하세요. 김대우 입니다. 이번에 소개해 드릴 내용은 ASP.NET 라우팅(Routing)과 URL Rewrite에 대한 내용입니다.

ASP.NET 라우팅이란 무엇인가?
URL Rewrite와 마찬가지로, ASP.NET에서 사용자 & 검색엔진 친화적인 URL을 이용 가능하도록 돕는 ASP.NET의 기능입니다. 대략 느낌이 오는 것처럼 .NET Managed Code와 Native Code의 차이점이 주가 될 것 같은 느낌이 들지요?

URL Rewrite는 왼쪽에서 보는 것처럼, HTTP 처리 파이프라인 중 “Begin Request” 영역에서 주로 처리되는 Native 처리기능을 수행합니다. 바꿔말하자면, HTTP 요청을 처리하는 절차들 중에서 비교적 앞쪽에서 일종의 Filter 형태로 동작하게 됩니다. ASP.NET 라우팅은 Managed Code로 작성되며 Resove Cache 처리와 Map Handler 처리에서 이루어지고 Execute Handler에서 역시 처리되게 됩니다. ASP.NET 라우팅 관련 내용은 아래 내용을 참고해 보세요.
링크 : ASP.NET 라우팅에 대한 상세한 정보

그렇다면, ASP.NET 라우팅과 URL Rewrite의 차이점은 무엇일까? 언제 URL Rewrite를 이용해아 하는지?
- URL Rewrite는 ASP, ASP.NET, PHP나 정적 HTML 파일(Static HTML file)과 같은 웹서버에서 처리되는 파일들에 대해서 동작 가능하다. 그러나, ASP.NET 라우팅은 오직 ASP.NET 웹 어플리케이션으로만 동작 가능하다.
- URL Rewrite는 도메인명, HTTP 헤더, 서버변수(Server variables)에 대해서 처리 가능하나, ASP.NET 라우팅은 URL Path와 HTTP Method 헤더에 대해서만 처리 가능하다.
- URL rewrite는 HTTP 리다이렉트(Redirect), 커스텀 상태코드(Custome status code), 요청 중단(Abort Request)가 가능하나, ASP.NET 라우팅은 이러한 처리를 하지 못한다.
- URL Rewrite는 제공되는 정해진 Rule 엔진(정규표현식 등)만을 이용해 처리 가능해 Rule에 대한 확장이 어려우나 ASP.NET 라우팅은 개발자가 얼마든지 기능을 확장하거나 커스터마이징이 가능하다.

이렇게 ASP.NET의 라우팅과 URL Rewrite의 차이점에 대해서 알아 보았습니다. 비슷한 역할을 하는 두 서비스는 각각 사용처가 어쩌면 명확해 보이네요. 감사합니다.
참조 : IIS URL Rewriting and ASP.NET routing

지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite

URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite

2009-10-15T02:41:22Z

지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성

안녕하세요. 김대우 입니다. 이번에 소개해 드릴 내용은 IIS7의 URL Rewrite 기능 세번째 시간으로, 요청필터링(Request Filtering) 기능과 URL Rewrite 기능에 대한 비교 내용입니다.

요청 필터링(Request Filtering)이 뭔가요?
요청 필터링은 IIS7에서 기본적으로 제공하는 보안 기능입니다. 혹시 아실지 모르겠습니다만, 이전에는 URLScan 이라는 녀석의 기능과 비슷하기도 합니다. 간단히 이녀석이 수행하는 기능은 IIS의 내장된 보안 기능으로 특정 URL이 들어올 경우 필터링, 특정 파일 확장자(Extension)을 요청할 경우 필터링, ASP.NET의 App_code와 같은 폴더에 대한 접근 필터링, HTTP 헤더의 길이 제한, HTTP의 특정한 verb에 대한 필터링 등이 가능합니다.

아울러, 요청 필터링은 이러한 보안 필터링 기능을 웹사이트단위 또는 웹서버 전체에 대해서 적용 가능합니다. 기존 URLScan3.0 버젼까지와는 약간 틀린 부분이지요.

참고로, 기존의 URLScan 3.0 버젼까지는 이러한 보안 기능들이 전체 웹서버에 대해서 적용되었습니다.
하지만, URLScan3.1부터는 보안기능들을 웹사이트 단위로도 구성이 가능하다고 하니 도움 되시길 바랍니다.
URLScan3.1 정보

요청 필터링에 대한 내용은 아래를 참고 하세요.
How to Use Request Filtering
Request Filtering <requestFiltering>

또 참고로, 요청 필터링을 IIS관리자에서 실행해 보고 싶으시다면?
먼저, IIS Administration Pack을 설치합니다.

다운로드 링크에 가시면 웹 플랫폼 설치 관리자가 실행되고 여기에서 “관리 팩 1.0”을 설치하세요.

그러면 IIS 관리자에서 Request Filtering을 수행 가능합니다.

자~ 그렇다면 다시 오늘의 주제인 요청 필터링과 URL Rewrite의 기능 비교에 대해서 알아 보도록 하지요.

요청 필터링과 URL Rewrite의 비슷한점은 무엇인가요?
두가지 기능 모두 URL이나 HTTP Request에 대한 보안 기능을 적용 가능하다는 점에서는 유사합니다. 하지만 아래와 같은 차이점이 있지요.

요청필터링은 순수한 보안 목적으로 제작되었습니다. URL Rewrite는 범용적인 URL 처리를 위한 목적으로 제작되었으며, URL Rewrite가 제공하는 보안 기능은 여러가지 기능들 중의 일부입니다.

간략히 표현된 요청 필터링과 URL Rewrite의 비교표 입니다. – 각각의 보안 기능들에 대해서 차이점이 존재 합니다.

그렇다면, 성능적인 측면에서는 어떨까요?
성능 측면에서는 두가지 기술 모두 영향을 줄 정도로 부하가 높지는 않습니다. 하지만, URL Rewrite의 경우 정규표현식을 이용하기 때문에 요청 필터링 보다는 약간 더 높은 시스템 리소스를 이용하게 됩니다. 요청 핕터링은 문자열에 대한 추출 작업만을 진행해 비교하기 때문에 시스템 리소스를 상대적으로 덜 사용하게 됩니다.

URL Rewrite와 요청 핕터링은 각각의 목적에 맞는 보안 기능들이 있으며 필요할 경우 두 기능을 조합해서 이용도 가능합니다. 많은 도움 되시길 바랍니다.

지난 포스트 링크
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성

URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성

2009-10-14T09:34:25Z

지난 포스트 링크
http://www.iiskorea.net/entry/URL-Rewrite-11-URL-재작성-1-소개-및-설치

지난 시간에 간략히 URL Rewrite의 역할과 기능을 소개해 드렸습니다. 이번 시간에는 URL Rewrtie를 실제로 사용해 보고 어떻게 이용하는지 간략히 설명 드리려고 합니다.

먼저, URL Rewrite를 왜 써야 합니까?
그렇다면 왜 URL Rewrite를 알아야 하는가? 간단하다, 다양한 웹 어플리케이션인 블로그나 CMS, 쇼핑몰 등도 Fancy URL과 Permanent Link가 제공하는 장점들을 기본적으로 제공하고 있다.
- XpressEngine
- Textyle
- Textcube
국내에서 가장 많이 사용되는 오픈소스 웹 어플리케이션들이며 모두 Rewrite 동작에 기반한 Fancy URL을 제공하고 있다. IIS7에서 역시 이러한 어플리케이션들을 구동시킬 수 있으며, 당연히 Rewrite 동작들을 어플리케이션들에 맞게 제공 가능하다. - Rewrite는 먼나라 이야기가 아니라, IIS를 운영하기 위한 필수적인 확장 기능이며, 당연히 IIS의 URL Rewrite는 국내 오픈소스 어플리케이션에서 제공하는 Rewrite Rule을 그대로 이용 가능하다.

Rewrite Rule 따라해보기
간단히 아래와 같은 역할을 수행한다고 가정해 보자.

Fancy URL http://localhost/article/342/some-article-title 을
http://localhost/article.aspx?id=342&title=some-article-title 으로 변환 하는 것이 목표다. – 그냥 보기에도 어려워 보인다. 흠…

Fancy URL인 위의 구조는 사람이나 검색엔진에는 친화적인 URL이지만, 개발자가 어플리케이션에 의해 처리되는 Request들을 받아 처리하기에는 적절하지 못하다.
당연히 Rewrite를 통해 Fancy URL을 재작성(Rewrite)하는 과정이 필요하다. 어떻게 진행 할 수 있을까?

        1: <%@ Page Language="C#" %>

       2: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

       3: <html xmlns="http://www.w3.org/1999/xhtml">

       4: <head>

       5: <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

       6: <title>URL Rewrite Module Test</title>

       7: </head>

       8: <body>

       9:       <h1>URL Rewrite Module Test Page</h1>

      10:       <table>

      11:             <tr>

      12:                   <th>Server Variable</th>

      13:                   <th>Value</th>

      14:             </tr>

      15:             <tr>

      16:                   <td>Original URL: </td>

      17:                   <td><%= Request.ServerVariables["HTTP_X_ORIGINAL_URL"] %></td>

      18:             </tr>

      19:             <tr>

      20:                   <td>Final URL: </td>

      21:                   <td><%= Request.ServerVariables["SCRIPT_NAME"] + "?" + Request.ServerVariables["QUERY_STRING"] %></td>

      22:             </tr>

      23:       </table>

      24: </body>

      25: </html>

테스트를 위해 위와 같은 텍스트 파일을 생성하고, 파일 이름을 article.aspx 파일로 저장한다. 이후, IIS의 웹사이트 루트에 저장하도록 한다. 본인의 경우는 http://localhost/article.aspx 형태가 되도록 구성했다. 이어서 Rule을 작성해 보도록 하자.

그렇다면 Rule(규칙), Pattern(패턴), Action(동작)이란 무엇인가?
알아야할 세가지 키워드가 존재한다. Pattern은 URL의 패턴을 의미한다. 즉, URL이 abc.com/article/123/abcd 형태라고 한다면 서버의 DNS 주소 뒤에 article이 오고 숫자가 오고 문자가 오는 형태의 패턴이라고 말할 수 있다. 즉, 이런 패턴을 치환하는 동작이 바로 Action이라고 보면 된다. 이렇게 패턴에 따라 정의한 동작이 있는 것이 하나의 Rule이라고 보면 되며 이런 Rule들이 여러개 조건에 따라 존재할 수 있다. 이 Rule들을 관리하게 쉽게 돕는것이 바로 URL Rewrite라고 보면 된다.

URL Rewrite를 실행

웹사이트를 선택하고, 이렇게 URL Rewrite를 실행한다.

우측 상단의 Add Rule을 실행한다.

Blank Rule을 선택합니다. – 물론 필요할 경우 Template 등을 선택할 수도 있습니다.

이어서, 위와 같이 Rule을 구성합니다.

Pattern 부분을 주의해서 보시면

^article/([0-9]+)/([_0-9a-z-]+)

이런 내용이 보이는데요. 의미하는 바는
- 시작 문자열이 article로 시작되고
- 하나 이상의 숫자가 처음 “/” 부터 존재하고
- 하나 이상의 “_” 또는 “-” 또는 알파벳 문자열이 두번째 “/” 이후에 존재하는
패턴을 의미 합니다. 즉, 이런 패턴일 경우에만 이 Rule이 동작 하겠지요.

이어서 Action 부분을 주의해서 봐 보시면

article.aspx?id={R:1}&title={R:2}

이런 내용이 보이는데요. {R:1}은 Rewrite된 패턴의 첫번째 리턴값, {R:2}는 두번째 리턴값이 들어간다고 보시면 됩니다.

URL Rewrite의 Rule은 어디에 저장 되는가?
IIS는 똑똑하게도 이러한 Rule을 기본적으로 웹사이트 루트디렉토리에 포함된 web.config에 저장하게 된다. 만약, 시스템 전체에 적용되는 Rewrite Rule을 이용하고 싶을 경우에는 당연히 시스템에서 구성하면 되며, 시스템에 구성한 Rule은 applicationhost.config에 저장되며 모든 웹사이트가 상속받아 실행하게 된다. 그렇다면, web.config에 저장된 rewrite rule은 어떤 모습일까?

   1:  <rewrite>

   2:    <rules>

   3:      <rule name="Rewrite to article.aspx">

   4:        <match url="^article/([0-9]+)/([_0-9a-z-]+)" />

   5:        <action type="Rewrite" url="article.aspx?id={R:1}&amp;title={R:2}" />

   6:      </rule>

   7:    </rules>

   8:  </rewrite>

이런 형태로 web.config에 저장된다. 즉, URL Rewrite 툴은 이런 Rule을 쉽게 제작하도록 도와주는 툴인 것이고, 실제 동작은 IIS의 Filter로 동작하게 되는 것이다. 그렇다면, URL Rewrite를 실행해 보면?
테스트 URL : http://localhost/article/234/some-title

이렇게 Rewrite가 처리되는 것을 볼 수 있다. Fancy URL에 대한 처리가 이렇게 가능해 진다. URL Rewrite는 이렇게 URL을 재작성해 어플리케이션에서 이용 가능하도록 URL을 재작성한다. URL “Redirect”는 어떨까? Redirect는 URL을 아예 옮겨버리는 작업을 진행하는 차이점이 있다.

URL Redirect를 테스트 해 보도록 하자.
이런 URL을 http://localhost/blog/some-other-title/543
http://localhost/article/543/some-other-title 이런 URL로 Redirect 시키려 할 경우를 진행해 보면

Pattern :

^blog/([_0-9a-z-]+)/([0-9]+)

Action 을 “Redirect”로 설정하고 Redirect URL을 아래처럼 구성한다.

article/{R:2}/{R:1}

테스트를 하기 위해 아래 링크를 수행한다.
http://localhost/blog/some-other-title/323
브라우져의 결과가 Redirect되어 http://localhost/article/323/some-other-title 로 이동된 것을 확인 가능하다.

Access Block Rule을 이용할 수도 있다.
이 경우는 해킹 시도와 같이 호스트명으로 처리되는 요청이 아닌 IP로 요청되는 시도를 blocking 할 수 있는 Rule이다. 즉, http://123.123.123.123 과 같은 형태의 요청을 기본적으로 block하고 http://abc.com 형태로 요청될 경우에만 통과 시키는 규칙으로 구성가능하다.(당연하겠지만, 이런 형태의 방어 처리는 IIS의 바인딩 설정이나 URL Scan 등에서도 처리 가능하다)

   1:  <rule name="Fail bad requests">

   2:        <match url=".*"/>

   3:        <conditions>

   4:          <add input="{HTTP_HOST}" pattern="localhost" negate="true" />

   5:        </conditions>

   6:        <action type="AbortRequest" />

   7:  </rule>

- 2번 라인은 Rule이 모든 URL 스트링에 대해서 동작하라는 의미이다.
- 4번 라인은 HTTP_HOST 값이 “localhost”이 아닐 경우에 대한 조건 처리이다.
- 6번 라인은 조건일 경우 요청을 취소 시키는 처리이다.

테스트를 위해서 http://127.0.0.1/article/234/some-title 과 같은 IP로 요청을 수행할 경우 Request가 중단되는 것을 확인 가능하다.

이렇게 URL Rewrite의 핵심적인 3개 기능을 알아 보았습니다.

1. Rewrite 기능을 이용한 URL 처리
2. Redirect 동작
3. Access Block 처리

다음 내용에서는
- 요청필터링과 URL Rewrite 비교
- ASP.NET 라우팅과 URL Rewrite 비교
- Apache의 mod_rewrite Rule을 Import해서 처리 가능한 URL Rewrite의 import 기능
- Rewrite Map 이용

내용에 대해서 알아 보도록 하겠습니다. 감사합니다.

[지난포스트 링크]
http://www.iiskorea.net/entry/URL-Rewrite-11-URL-재작성-1-소개-및-설치

URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치

2009-10-01T16:13:00Z

URL Rewrite의 기본 역할? 어디에 쓰는 건가요?

URL Rewrite는 사용자가 기억하기 더 쉽고, 검색 엔진에 의해 검색될 수 있도록 하는 URL을 만들어 주는 IIS의 확장기능(Extension) 입니다. Rewrite 본연의 기능을 보시려면, 아래의 화면을 통해 말씀 드리겠습니다.

이렇게 복잡한 URL 링크는 사용자나 검색엔진에게 친화적이지 않습니다. 보통 이런 URL을 Dirty Link 라고도 표현하는데요, 이를 보완하기 위해 아래에 보시는 깔끔한 링크처럼 사용자 편의적이고 검색엔진에 친화적인 URL로 만들어주는(Fancy URL) 기능이 바로 URL Rewrite가 지원하는 대표 기능입니다.(느끼시는 것처럼 그 외에도 다양하고 많은 기능들을 제공합니다.)

Rewrite에서 말하는 Rule 이란 무엇입니까?

이렇게, IIS Rewrite에서 특정 조건의 URL을 Fancy URL로 바꿔주는 하나하나의 규칙을 “Rule” 이라고 표현합니다.

Rule template이나 rewrite map 등을 쉽게 구축 가능하도록 돕는 이 기능은 HTTP 헤더의 URL과 서버변수(Server variable) 등에 대해서 처리가 가능하며 재정의된 응답을 사용자에게 내려 보내거나 HTTP 요청을 중지하는 다양한 규칙을 만들 수도 있으며, 보안 기능 등에도 활용 가능합니다. ? 차근차근 보여 드리겠습니다.

URL Rewrite의 주요한 특징 및 기능

- Rule을 기반으로 동작해 다양한 로직이나 표현식, 개발 루틴 등을 이용 가능해 강력한 rewrite 처리가 가능하빈다.

- 정규 표현식을 이용 가능합니다. ECMA-262 호환 정규 표현식 구문을 사용 가능합니다.

- 와일드카드(wild card) 패턴 매칭을 이용 가능합니다.

- Rewrite는 HTTP 헤더에 기반한 URL과 서버변수(Server variable)에 대해서 처리합니다.

- 다양한 rule 동작을 제공해, 단순한 rewriting 뿐만 아니라, HTTP 리다이렉트, HTTP 요청 중지, 커스텀 상태 코드를 클라이언트에 전달하는 처리 역시 가능합니다.

- IIS 커널 모드와 User 모드 출력 캐시를 지원해 빠른 성능을 제공합니다.

- 문자열 처리 함수를 제공합니다. 기본 포함된 문자열 처리 함수들과 다양한 변환 함수 등의 Action 처리가 가능합니다.

- Rewrite map을 지원합니다. ? 이는 다수의 매핑 rule에 대한 정의가 편리합니다. GUI로도 생성 가능합니다.

- Rule 템플릿을 지원

- IIS의 관리툴과 완벽하게 상호 작용해 관리의 편의성이 높고 GUI 기반의 rule 생성, 체크 테스트,디버깅 등을 도와 줍니다.

- mod_rewrite의 rule도 손쉽게 GUI를 통해 import를 할 수 있습니다.

- 국내에서 가장 많이 사용되는 오픈소스 웹 어플리케이션의 rewrite rule도 완벽하게 지원합니다. 요것도 차근차근 보여 드리겠습니다.

URL Rewrite 다운로드

개인적으로는 웹 플랫폼 인스톨러(Web Platform Installer)-WPI 2.0을 이용해 다운로드 하실 것을 추천해 드립니다.

웹 플랫폼 인스톨러 http://www.microsoft.com/web/downloads/platform.aspx

웹 플랫폼 인스톨러는 윈도우 서버에서 사용되는 모든 웹 플랫폼 프레임워크, 웹 어플리케이션, IIS 확장 기능 및 SQL서버와 같은 제품 등에 대한 설치와 구성을 돕는 최고의 툴입니다. ? IIS로 웹 어플리케이션을 구동하기 위한 최적의 툴이지요.

웹플랫폼 ? 웹서버의 사용자 지정 ? 일반 HTTP 기능에서 설치 가능합니다.

또는 http://www.iis.net/extensions/URLRewrite 링크에서 다운로드 가능합니다. X86용과 X64용이 모두 제공되는 적절한 파일을 받으시면 됩니다.

더 많은 다양한 IIS 관련 강좌는 IISKOREA 커뮤니티 http://www.iiskorea.net 에서 확인 하실 수 있습니다.

실버라이트 설치 실패를 해결하는 방법 - Silverlight

2009-05-14T11:49:01Z

안녕하세요. 준서아빠 입니다.

소수의 특수한 사용자 환경일 경우에 실버라이트 설치가 잘 안되는 경우가 있을 수 있는데요. 설치가 되지 않는 사용자 분들에게 아래 정보를 제공해 주실 수 있을 거에요. 도움 되시길 바랍니다.

이 포스트의 내용을 크게 세부분으로 구성되어 있습니다.

1) 웹페이지 HTML에서 설치 불가 메세지 처리 방안
실버라이트 영상 서비스 페이지 접근 후 설치 불가 메시지가 발생할 수 있습니다. 이러한 HTML 웹페이지에서 발생하는 오류를 처리하기 위한 가이드 내용 입니다.

2) 실버라이트 설치 중 발생하는 장애 처리 방안
아래처럼 실버라이트 설치 화면 중에 발생하는 장애를 처리하기 위한 방안을 제공해 드립니다.

3) 설치가 완료된 후 실버라이트 동영상 서비스 이용 중 발생하는 장애 처리 방안
설치가 잘 진행되었으나 영상이 플레이 되지 않는 장애를 처리하는 내용입니다.

1) 웹페이지 HTML에서 설치 불가 메세지 처리 방안
HTML 웹페이지는 Javascript로 설치 가능한 OS나 브라우저를 미리 검사합니다. 만약 사용자가 설치 불가라는 메시지를 확인 하셨다면 OS의 버전과 브라우져 버전을 확인 하시고, 설치 권장 사항을 전달 하시면 됩니다.

Q 1-1. 지원하지 않는 운영체제 또는 브라우저라는 메시지 발생
A. 실버라이트가 지원하지 않는 OS나 브라우져를 이용하시는 것으로 예상됩니다. 사용자의 운영체제 및 브라우저 환경을 확인하시고, 지원하지 않을 경우 안내 하시면 됩니다.
추가정보 : 마이크로소프트 실버라이트의 공식 시스템 요구사항
http://www.microsoft.com/silverlight/resources/install.aspx#sysreq
(참고로, Windows7 베타 이상과 비공식이지만, 구글 크롬브라우저에서도 사용 가능합니다.)

Q 1-2. HTML 웹페이지에서 실버라이트 설치하기를 클릭하면 브라우져 창이 뜨면서 “페이지를 찾을 수 없음 또는 빈 페이지가 뜹니다.”
A. 아마도, 바이러스나 악성 프로그램에 의해 *.microsoft.com 페이지 접근이 제한되어 페이지를 찾을 수 없습니다라는 오류가 난 것 같습니다. hosts 파일 변조나 브라우져 프록시 조작이 되었을 수 있습니다. 아래 임시로 올려둔 실버라이트 설치 경로를 알려 주시고, 수동 다운로드 후 설치 시켜 주신 후 실버라이트 영상 서비스에 접근 하시면 문제 없으실 것입니다.
임시 다운로드 경로 : http://cid-dd16b25b3aab44e9.skydrive.live.com/browse.aspx/Silverlight2

Q 1-3. 실버라이트를 설치했으나, 동영상 서비스에서 계속 설치되지 않았으니 다시 설치하라고 합니다.
A. 브라우저 설정으로 인해 HTML이 캐시가 되어, 발생한 것으로 예상됩니다. 인터넷 익스플로러에서 컨트롤+F5를 눌러 새로고침하거나(캐시를 지우고 강제 리프레시) 만약 동작하지 않으면 아래 절차로 캐시를 지우고 재시도 하시길 바랍니다.
모든 브라우져를 종료합니다.
1. 시작 -> 제어판 -> 인터넷 옵션을 실행합니다.
2. 일반탭 선택후 '삭제' 버튼 클릭합니다.
3. '즐겨찾기 웹 사이트 데이터 보존' , '임시 인터넷 파일' , 선택된 상태에서 '삭제' 버튼 클릭 합니다.
이 설정이 동작하지 않으시면, 다음 절차로 인터넷 익스폴로러를 초기화 시키는 가이드를 시도해 보세요.
4. 보안탭 선택후 '모든 영역을 기본 수준으로 다시 설정' 을 한번 클릭합니다.
5. 고급탭을 선택하여, '원래대로' 클릭후 '다시 설정' 버튼 클릭 합니다. '고급 설정 복원' 버튼을 클릭합니다. 이후 브라우져를 실행하고 다시 시도해 보시면 해결됩니다.

2) 실버라이트 설치 중 발생하는 장애 처리 방안
HTML 웹페이지에서 체크가 1차적으로 진행된 후 다운로드 과정을 거쳐 다음과 같은 실버라이트 설치 화면이 실행됩니다. 일반적인 “인스톨 프로그램”과 같으며 반드시 오류 메시지 번호와 설명을 확인 후 진행 하셔야 합니다.

반드시 위 화면 아래쪽의 “추가 정보” 링크를 클릭해 “오류번호”를 확인 해야 합니다.

예를 들어, “추가정보” 클릭시 아래의 링크로 이동될 수 있습니다. – 한글로 표시 됩니다.
예시 화면 : http://www.microsoft.com/silverlight/resources/help.aspx?errorID=1504

이렇게 메시지 ID “15XX” 통해 오류 정보를 확인 가능합니다. 이 오류 번호와 메시지로 실버라이트 설치가 되지 않는 원인을 파악 가능합니다.

Q 2-1. “1509” 오류와 함께 실버라이트가 설치되지 않는 환경이라는 오류가 발생할 경우
A. 실버라이트는 윈도우XP 서비스팩2 이상에서 설치가 가능합니다. 사용자의 운영체제 버전이 윈도우XP 서비스팩이 없는 버전이거나, 윈도우XP 서비스팩1 환경일 수 있습니다. 이 경우에는 서비스팩2 이상을 다운로드 하시도록 권장하십시오. 또는, 사용자의 OS나 브라우저를 다시 확인하시고 설치가 가능한 버전인지 체크 하시면 됩니다. 윈도우XP 서비스팩2 미만일 경우에는 다음 절차로 설치 가능합니다.

1) 윈도우 업데이트를 실행해 최신의 운영체제 환경을 유지 하십시오
- 시작 / 프로그램 항목에서 Windows Update를 실행 하십시오
또는 바로 아래, 2안의 수동 설치 링크를 통해 설치 하시길 바랍니다.
2) 마이크로소프트 공식 XP 서비스팩 페이지를 통해 수동 설치
최신 버전의 XP 서비스팩 다운로드 후 설치 하시길 바랍니다.
참고자료 : 최신 Windows XP 서비스 팩을 구하는 방법
http://support.microsoft.com/kb/322389/

Q 2-2. “1503” 현재 운영 환경에서 지원되지 않습니다"와 같은 오류가 발생할 경우
A. 사용자가 X64나 IA64 와 같은 64비트 환경을 이용하실 가능성이 있습니다. X64는 X86과 호환되는 모드가 포함되어 있으며, 사용자의 OS 버전이 X64일 경우에는 32Bit용 인터넷 익스플로러 실행해 다시 접속을 가이드 해 주시면 됩니다.
1) PC에서 탐색기를 실행합니다.

2) C:\Program Files (x86)\Internet Explorer\iexplore.exe 를 탐색기에서 실행하면 32Bit 인터넷 익스플로러가 실행됩니다.
3) 이 익스플로러로 실버라이트 영상 서비스로 접근하시면 동영상을 시청 하실 수 있습니다.

32 bit 인터넷 익스플로러 경로 "C:\Program Files (x86)\Internet Explorer\iexplore.exe"
64 bit 인터넷 익스플로러 경로 "C:\Program Files\Internet Explorer\iexplore.exe"

(참고자료) IA64는 인텔 아이테니엄 기반의 서버용 프로세서로 이 OS에서는 실버라이트가 지원되지 않습니다. 혹은, 사용자의 CPU 하드웨어가 매우 오래되어 펜티엄1 기반의 인텔MMX나(펜티엄2부터 기본포함) AMD SSE 명령을 지원하지 않을 경우 – 보통 7년 이상 된 CPU 환경 – 설치가 불가할 수 있으니 가이드가 필요합니다. 아울러, 매우 오래 전에 발표된 윈도우98, 윈도우ME에서는 실버라이트2 버젼 설치가 불가합니다. 설치 가능 OS나 브라우져를 확인하기 위해 http://www.microsoft.com/silverlight/resources/install.aspx#sysreq 링크를 참조 하시길 바랍니다.

Q 2-3. "고진샤"사의 특정 넷북을 이용하고 있으나 설치시 1503오류 - "현재 운영 환경에서 지원되지 않습니다"라는 메세지가 나오며 설치가 되지 않습니다.
A. 고진샤의 넷북 중 / AMD Geode CPU를 이용하는 매우 특수한 넷북에서는 실버라이트 설치가 불가능합니다. AMD Geode CPU는 멀티미디어 처리에 이용되는 명령인 SSE라는 명령어들을 지원하지 않기 때문이며 이 SSE는 보통 7년 전 CPU 부터는 기본적으로 사용되었으나 이 AMD Geode CPU만 지원하지 않는 매우 특수한 경우 입니다. 참고로 이 CPU는 원래 영상 서비스 등이 아닌 특수한 환경의 임베디드(Embedded) 장치를 위해 디자인된 CPU입니다.

Q 2-4. “1601” 오류와 함께 윈도우즈 인스톨러(Windows Installer)가 필요합니다.
A. 윈도우 인스톨러가 설치되지 않았거나 손상된 고객입니다. – 대부분, 비정상적인 방법으로 개인이 패키징한 서비스팩이 포함된 윈도우XP를 어둠의 경로 등으로 다운로드 받아 이용할 경우 발생 가능합니다. - 이 경우에는 최신의 윈도우 인스톨러 설치 가이드 링크를 통해 해결 가능합니다.
다운로드 링크 : Windows Installer 4.5 Redistributable - 한국어
http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=5a58b56f-60b6-4412-95b9-54d056d6f9f4
페이지 아래쪽의 WindowsXP-KB942288-v3-x86.exe 3.2 MB 파일을 다운로드 후 설치 하시고, 시스템을 재 시작 하신 후 다시 실버라이트 영상 서비스 보기를 시도 하시면 해결됩니다.
참고자료 : http://support.microsoft.com/kb/292539/

이외의 이슈에 대해서는 반드시 “추가정보”를 클릭하신 후 “메시지ID” 번호와 오류 메시지를 통해 오류 원인이나 설치 불가 원인을 확인 가능하니 도움 되시길 바랍니다.

3) 실버라이트 동영상 서비스 이용 중 발생하는 장애 처리 방안

실버라이트 설치가 끝나면 대부분 문제 없이 실버라이트 영상을 보실 수 있습니다. 그러나, 특수한 경우 영상이 플레이 되지 않거나, 플레이 중 오류가 표시될 수 있습니다.

Q 3-4. 영상부분 화면이 흰색으로(배경화면색) 나오고 영상이 플레이 안됩니다.
A. 브라우져가 캐시된 경우로 예상됩니다. 또는 배경화면 색깔이 나타나는 경우 모든 브라우저를 종료하고 다시 시작해 주십시오.
만약, 모든 브라우져를 종료한 후에도 같은 증상이 있으실 경우에는 다음 절차로 브라우져 캐시를 지우거나 설정을 초기 상태로 조절해 보시길 권장 드립니다.
1. 시작 -> 제어판 -> 인터넷 옵션을 실행합니다.
2. 일반탭 선택후 '삭제' 버튼 클릭합니다.
3. '즐겨찾기 웹 사이트 데이터 보존' , '임시 인터넷 파일' , '쿠키' , '기록' 선택된 상태에서 '삭제' 버튼 클릭 합니다.
이 과정을 실행후에도 동작하지 않으면 아래 절차대로 진행해 보세요.
4. 보안탭 선택후 '모든 영역을 기본 수준으로 다시 설정' 을 한번 클릭합니다.
5. 고급탭을 선택하여, '원래대로' 클릭후 '다시 설정' 버튼 클릭 하시고, '고급 설정 복원' 버튼을 클릭합니다.
만약 위의 방법으로도 해결이 안되실 경우, 제어판-프로그램 추가 제거 툴에서 사용하지 않는 툴바나 브라우져 확장 기능에 사용될 수 있는 툴들을 가능한 모두 제거 하신 후 다시 시도 하시길 바랍니다. 만약, 다른 실버라이트 영상 서비스 웹사이트에서는 문제가 없으나, 특정 웹사이트의 실버라이트 영상 서비스만 문제가 될 경우에는 문제의 사이트에 대해 “광고 차단 설정”이 되어 있는지 확인 해 볼 필요가 있습니다.(광고 영상 제공 URL이 차단되어 후속 동영상이 안나올 수 있음)

Q 3-5. 영상이 거의 5배속 이상으로 매우 빠르게 플레이됩니다.
A. 특정 영상만 빠르게 플레이가 된다면, 해당 영상 만인코딩에 문제가 있는 경우이며, 모든 영상들이 빠르게 플레이가 된다면 특정 사운드 카드 드라이버가 특수한 조건으로 시스템에 설치된 사운드 장치와 맞지 않거나 잘못 설치 되었을 때 발생 하는 것으로 보고되어 있습니다.
현재 보고된바로는, XP에서 SoundMAX 장치 “SoundMAX Integrated Digital HD Audio” 의 드라이버가 5.10.1.4160 이고 특수한 경우에만 발생 가능합니다. 아래 절차대로 진행해 보시길 바랍니다.

1) 내컴퓨터 – 마우스 우버튼 후 속성 클릭
2) 하드웨어 탭 – 장치 관리자 클릭
3) “사운드, 비디오 및 게임 컨트롤러” 에서 SoundMax 드라이버 선택 후 마우스 우버튼 후 제거
4) “사운드, 비디오 및 게임 컨트롤러” 선택 후 마우스 우버튼 후 “변경된 하드웨어 검색” 실행
5) 자동으로 호환되는 “Microsoft UAA Fuction Driver for High Definition Audio – Adi 1986” 설치
6) 실버라이트 및 다른 프로그램들의 영상 서비스 정상 동작됨.
참고 : ASUS 웹사이트의 SOUNDMAX 드라이버 다운로드 정보는 잘못된 정보이며, 이는 현재 ASUS에 보고된 상태 입니다.

Q 3-6. “uaclauncher.exe - 잘못된 DLL 재할당” 오류 발생
A. 위의 오류와 함께 “user32.dll 시스템 DLL이 메모리에 다시 할당되었습니다. 응용프로그램이 올바르게 실행되지 않을 것입니다.
"D:￦WINDOWS￦system32￦SHELL32.dll DLL이 Windows NT 시스템 DLL에 대해 예약된 주소 범위를 차지했기 때문입니다. DLL을 제공한 업체에 문의하여 새 DLL을 받으십시오.”
라는 메시지가 발생할 경우 아래 절차대로 처리 가능합니다.

1) Silverlight 설치 파일(Silverlight.2.0.exe)을 컴퓨터로 다운로드 합니다.
2) C드라이브 최상위 위치로 복사합니다.(C:\ 경로)
3) 명령프롬프트에서 아래 명령을 수행합니다.
c:\silverlight.2.0.exe /x:c:\tempsilverlight /u
4) 탐색기로 C:\tempsilverlight 폴더로 이동 후 install.exe 를 실행하면 설치가 진행됩니다.

Q 3-7 실버라이트를 수동으로 완전 제거후 재설치하고 싶습니다.
A. 아래 방법으로 실버라이트를 완전히 수동 제거 가능합니다. 브라우져를 종료하고 아래 절차를 수행
1) 윈도우즈 인스톨러 클린업 유틸리티 다운로드 후 실행 http://support.microsoft.com/kb/290301
실행 후 "Silverlight"이 나오면 선택 후 "Remove" 클릭해 1차적으로 삭제합니다.(리스트에 안나와도 무방합니다. 바로 아래 절차를 진행 하셔도 됩니다.)
2) regedit.exe를 시작-실행 에서 수행 후 HKEY_LOCAL_MACHINE\Software\Microsoft\Silverlight 키를 삭제
3) Program files 하위의 Microsoft Silverlight 폴더를 삭제 후 다시 설치를 진행하시면 잘 되실 겁니다.

Q 3-8. 소리만 나오고 영상이 나오지 않습니다.
A. 해당 플레이어가 소리만 제공하는 플레이어일 수 있습니다. 또는, 선택한 미디어가 소리만 제공하는지 먼저 확인할 필요가 있습니다. 그렇지 않다면, 듀얼 모니터 이상을 쓰실 경우 “주모니터”에서만 영상이 나오실 수도 있으며 특정 비디오 카드 드라이버가 설정이 되어 있을 수 있습니다. 또는, 해당 사이트에 대해 "광고 차단" 설정이 되어 있을 경우에도 발생 할 수 있습니다.

Q. 3-9. 광고 영상이나 다른 실버라이트 영상 서비스 사이트들의 영상은 잘 나오는데 특정 사이트의 영상만 나오지 않습니다.
A. 영상을 제공하는 사이트가 *nefficient.co.kr이고 브라우저의 신뢰할 수 있는 사이트 목록에 포함되어 있을 경우 발생 가능합니다.
먼저, 플레이가 되지 않으시는 분의 시스템의 IE 브라우져에서
도구 - 옵션 - 보안탭 - 신뢰할 있는 사이트 - 사이트버튼 클릭
을 진행하시고 확인해 보시면 *.nefficient.co.kr 사이트가 포함되어 있을 수 있습니다.
이 사이트를 실회할 수 있는 사이트 목록에서 임시로 제거 하신 후 시도해 보시면 잘 되실 것입니다.

이 내용은 특정 단체나 웹사이트와 관계 없으며, 순수하게 마이크로소프트 실버라이트가 설치되지 않을 경우 이용 가능한 조치 들이니 도움 되시길 바랍니다.

DocZoom, Cool Silverlight DeepZoom based E-doc management commercial solution of Korea.

2008-12-17T15:02:49Z

I’m so delighted to introduce “DocZoom” solution, the cool Silverlight DeepZoom based “commercial” E-document management solution of Korea.

DocZoom enhances the usage of electrical documents as users can easily access electrical documents with more flexibility over the limitation of a normal solution, which is standardized by Full Silverlight DeepZoom technologies.

It’s commercial solution for E-Book management system and development company already sold this solution several companies include government county office.

Also, I believe this solution does shows how Silverlight DeepZoom technology enhancing experience of E-Book solutution.

Doc Zoom & Docflow screen images.

[DocZoom Solution DEMO & DEMO steps]

DocFlow document management system of Korean country “Songpal” office sample.

“MapZoom” solution for tourist of “KwangGyo mountain”.

”ShopZoom” solution for Digital Shop E-Book brochure

“PhotoFlow” photo album sample

Just upload Office format or XPS, PDF to server and then server system *automatically* generate Silverlight DeepZoom format.

Also, user can attach additional interactive information such like video, link and sound on the document.

Developer company : www.doczoom.co.kr

Open Source UGC project of Korea, UCCLight

2008-10-10T04:54:16Z

UCCLight Open Source Project

UCCLight DEMO Video

Full media service with Microsoft Technologies
UCCLight project developed by “http://Hoons.kr” community open source project made by Microsoft technologies, product and services.

Media Encoding
Automation encoding by Microsoft Expression Encoder 2 SDK. End-user can upload various format of media to encoding server and it transcoding to WMV, Silverlight format.

Silverlight media player
Silverlight support WMV, VC-1 codec. This open source project implemented Silverlight 2 based media player and populate user information with WCF(Windows Communication Foundation) from Server.

ASP.NET Web site
UCCLight website built on ASP.NET technology. User can upload media and list media from it. Also, web site connect to database, SQL Server 2008 database with LINQ to SQL technologies

Additional information
Windows Server 2008 and IIS7(Internet Information Server) media pack, UCCLight does using Bit Rate Throttling and server-site playlist for enhanced media service.

Source code download, demo site and project information
You can download full source code, below Microsoft codeplex link.

UCCLight source code download :
http://www.codeplex.com/ucclight

UCCLight Demo site(Locate in Korea) :
http://ucclight2.dotnetngene.kr/Contents/List.aspx

Install guide :
Check Codeplex link, Release information.

License information
For your information, this is open source project. For using commercial purpose, you should contact UCCLight project leader, “Kyoung Hoon Park”(hoonsbara@hotmail.com)

Product & Technologies
Silverlight 2
Expression Encoder
ASP.NET
WCF
Windows Server 2008
IIS 7 Media Pack
SQL Server 2008

Deep Zoom Viewer Lite

2008-04-18T04:44:43Z

[Silverlight] IIS7 미디어팩(Media Pack)의 Web Playlist 설정

2008-04-04T07:45:25Z

Silverlight2의 미디어 기능과 함께 연계 가능한 Windows 2008 서버의 IIS7의 내용이 공개 되는데요.
최근 Windows 2008 서버에 포함된 IIS7과 미디어팩의 Play List를 이용하는 방안이 공개 되었습니다.

IIS 7 Media Pack Web Playlists is Live
http://blogs.iis.net/vsood/archive/2008/02/28/iis-7-media-pack-web-playlists-is-live.aspx

웹 플레이 리스트 기능은 여러가지 방안으로 비지니스 시나리오와 연계 가능한데요.
특히, 광고 모델이나 수익화 모델과 연계 가능한 부분은 참고 하시면 좋을 것 같습니다.

위의 내용은 나중에 천천히 풀어 보도록 하지요.