Feb  9 12:10:57 server01 smbd[2945]: [2009/02/09 12:10:57, 0] printing/print_cups.c:cups_connect(69)
Feb  9 12:10:57 server01 smbd[2945]:   Unable to connect to CUPS server localhost:631 - Connection refused

Feb 13 09:56:19 server01 smbd[14757]: [2009/02/13 09:56:19, 0] lib/util_sock.c:get_peer_addr(1224)
Feb 13 09:56:19 server01 smbd[14757]:   getpeername failed. Error was Transport endpoint is not connected
Feb 13 09:56:19 server01 smbd[14757]: [2009/02/13 09:56:19, 0] lib/util_sock.c:write_data(562)
Feb 13 09:56:19 server01 smbd[14757]:   write_data: write failure in writing to client 116.126.102.114. Error Connection reset by peer
Feb 13 09:56:19 server01 smbd[14757]: [2009/02/13 09:56:19, 0] lib/util_sock.c:send_smb(761)
Feb 13 09:56:19 server01 smbd[14757]:   Error writing 4 bytes to client. -1. (Connection reset by peer)

고대하던 정식판이 나와주셨다.

beta에서 특정 버전만 깔리는 까칠함을 보여주셨는데

이번엔 그나마 영문판 이라면 패스해 주시는 관대함을 배푸셨다.

한글판은 대략 6월 넘길듯 -_-

from : http://msdn2.microsoft.com/ko-kr/library/24b2tcy0(VS.80).aspx

리소스 전용 DLL은 아이콘, 비트맵, 문자열 및 대화 상자 등의 리소스만 들어 있는 DLL입니다. 리소스 전용 DLL을 사용하면 여러 프로그램 간에 동일한 리소스 집합을 쉽게 공유할 수 있습니다. 여러 언어로 지역화된 리소스가 있는 응용 프로그램을 제공하는 것도 좋은 방법입니다(MFC 응용 프로그램의 지역화된 리소스: 위성 DLL 참조).

리소스 전용 DLL을 만들려면 새로운 Win32 DLL(비 MFC) 프로젝트를 만든 다음 이 프로젝트에 리소스를 추가합니다.

• 새 프로젝트 대화 상자에서 Win32 프로젝트를 선택한 다음 Win32 프로젝트 마법사에서 DLL 프로젝트 형식을 지정합니다.

• 해당 DLL에 사용할 문자열 또는 메뉴와 같은 리소스가 포함된 새 리소스 스크립트를 만든 다음 .RC 파일로 저장합니다.

• 프로젝트 메뉴에서 기존 항목 추가를 선택한 다음 새로 만든 .rc 파일을 프로젝트에 삽입합니다.

• /NOENTRY 링커 옵션을 지정합니다. /NOENTRY 옵션은 링커가 _main에 대한 참조를 DLL에 링크하지 않도록 하며, 리소스 전용 DLL을 만들 때 반드시 사용해야 합니다.

• DLL을 빌드합니다.

리소스 전용 DLL을 사용하는 응용 프로그램은 LoadLibrary를 호출하여 명시적으로 DLL에 링크해야 합니다. 리소스에 액세스하려면 모든 종류의 리소스에 대해 작동하는 일반 함수인 FindResource 및 LoadResource를 호출하거나 다음과 같은 특정 리소스 관련 함수 중 하나를 호출해야 합니다.

• FormatMessage

• LoadAccelerators

• LoadBitmap

• LoadCursor

• LoadIcon

• LoadMenu

• LoadString

응용 프로그램이 리소스 사용을 마친 경우에는 FreeLibrary를 호출해야 합니다.

: 그렇게 스크랩은 올리지 않으려 했건만...

웹서버의 스트리밍데이타를 압축해서 보내자는 말이 나왔다.

당연히 mod_gzip을 찾아보고 적용 시키는 중에 죽어도 컴파일이 안되는 것이 발생해서...

그럼 php에서 한다고 생각해서 php 모듈을 찾다가 보니 그다지 뾰족한 것이 없었다.

더욱 찬찬히 찾아보니...

웬걸

삽질이었다.

Apache2 이상에서는 mod_gzip 대신에 mod_deflate에서 압축을 담당하는 것이었다.

적용을 해보자

1) httpd.conf
LoadModule deflate_module modules/mod_deflate.so
LoadModule headers_module modules/mod_headers.so
가 있는지 확인하자.

2) 적용할 디렉토리를 찾는다.
vhost를 사용하지 않으면 httpd.conf에 있을 것이고
vhost 사용시에는 각 도메인의 디렉토리를 찾는다.

2-1) 모두 압축하고 하지 않을 필터를 설정
<Directory 경로~>
SetOutputFilter DEFLATE
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4\.0[678] no-gzip
BrowserMatch \bMSI[E] !no-gzip !gzip-only-text/html
SetEnvIfNoCase Request_URI \
\.(?:gif|jpe?g|png)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary
</Directory>

2-2) 압축할 필터를 설정
<Directory 경로~>
AddOutputFilterByType DEFLATE text/html text/plain text/css text/javascript text/xml application/x-javascript
</Directory>

3) apachectl -k restart
적용 완료 -_-


확인은 httpwatch 같은 것으로 패킷캡쳐 해보면 안다.

참고 site

http://httpd.apache.org/docs-2.0/mod/mod_deflate.html

1. Vista 설치
2. administrator 활성화 및 당 계정으로 로그인
3. IIS 7 설치 
   1. [인터넷 정보 서비스]->[웹 관리 도구]->[IIS 6 관리 호환성]의 하위 아이템을 모두 체크
      정확히 뭐가 필요한건지 파악안되었음 -_-
   2. [인터넷 정보 서비스]->[World Wide Web 서비스]->[응요 프로그램 개발 기능]의 하위 아이템을 모두 체크
4. Windows SDK를 먼저 설치 하려고 하면 Microsoft Document Explorer 2005 미설치 오류로 종료 당함
5. 기본적인 순서인 오래된 프로그램 부터 설치하는 방법을 택함
   1. Visual Studio 2003 설치
      1. 설치시 "FrontPage Server Extensions"을 설치하라는 메시지가 출력되고 설치 안하면 저것이 깔린 원격 컴퓨터에서만 웹 응용 프로그램 및 웹 서비스를 호스팅할 수 있다는 협박을 한다. 하지만 3-1. 때문에 괜찮다.
      2. SP1 및 보안 패치 설치
      3. 실행파일을 관리자 권한으로 실행 되도록 지정
   2. Visual Studio 2005 설치 
      1. 전체 설치 
      2. SP1 설치, Vista용 VS2005 SP1 Update 설치, MSDN 업데이트
      3. Windows SDK 설치 (권장 Version : 6.1.6000.16384)
      4. VS2005 Extensions for WWF, VS2005 Extensions fot WFX(WPF & WPF/E, WCF) 설치
      5. 선택 설치 - VSTO(Visual Studio 2005 Tools for Office Second Edition), VSTASDK(Visual Studio 2005 Tools for Applications SDK)등 설치

이 글은 스프링노트에서 작성되었습니다.

이전에 Internet Explorer 7(이하 IE7)가 나오면서 IE7의 본연의 기능 외에 vista 에서 IE7의 보호모드와 UAC와 관련된 칼럼, 기사, 리뷰, 투고 등의 글을 보면서 발로 코딩하는 개발자지만 윈도우 쪽과 더 관련 있는 사람으로써 갑갑했다.
그리고 ActiveX에 해당하는 것에 대해서만 요리조리 꼼수만 연구해보다가 다른 바쁜일들로 시들해졌다.

최근에 Vista Ultimate K 64bit를 설치해보면서 이런저런 생각이 든다.

우선 MS에서 선전하는 Vista의 좋아진 점에 대해서 나열해 보면 다음과 같다.
1. 더욱 좋아진 UI : 맥 OS 이젠 더이상 부러워하지 마세염~
2. 더욱 편리해진 OS 환경 : OS 하나로 끝장 볼 수 있어염~
3. 더욱 안전해진 OS 및 인터넷 환경 : 다른 프로그램 필요 없이 Virus나 Spyware에서 당신의 PC를 보호할 수 있습니담~
4. 더욱 통합에 편리한 OS 환경 :

뭐... 다 좋고 백만번 인정해도 답답해지는 한켠의 의문의 무엇인가.

우선 MS에서 계속해서 붙잡고 있는 MS의 이중적인 잣대를 보이는 것 같다. 이제 더이상의 이슈는 특정 OS가 아니다. 게임을 하거나 특정 프로그램을 돌리거나(과거에 맥의 유니크함이 빛나던 것을 생각해보라, 그것은 하드웨어에서가 아니라 프로그램들에서 기인한다) 등등이 이제 많이 해체되고 있다.
여러분야들이 있지만 대표적으로 동영상 편집을 생각해 보자면 과거 리니어 편집기니 디코더, 엔코더, DT, 각종 기기들을 렉마운트 형태로 보관하고 아날로그 혹은 디지털로 옮기던 시대에서 90년대 어느샌가 환경이 모두 PC로 들어오고 그로 인해서 PC라는 기기가 주목을 받게 되었다. 인쇄, 음악 작업도 이와 같다. 이것과 더불어 게임이라는 분야도 그랬다.

헌데 최근엔 어떻게 달라지는가
첫번째가 달라지는 환경.
이제 다시 새바람이 불고 있다. 하나는 웹, 그리고 다음은 표준화다.
사용자의 브라우징을 넘어 이제 이제것 쌓아왔던 모든 기술을 헤체하고 녹이고 응축시키고 다시 만드는 공간으로 자리잡고 있는 곳이 웹이다. disconnect한 시대에는 OS가 기반이었다. 하지만 webable 한 시대에서는 기반은 웹이다. 그 위에 표준화라는 것으로 특정 OS, 특정 브라우저에 복속되는 웹환경을 벗어나고 있다. 정의가 쉬우면서도 힘든 곳이 웹이라

두번째가 해체화의 바람이다.
모던이라는 혁신이 온 후에 다시 온 것은 포스트 모던이다.
웃긴게 포스트 모던은 모던을 여러부분에서 계승하지만 적어도 표현에 있어서는 모던함을 거부한다는 것이다.
통합의 시대를 지나 이제 다시 해체의 시대가 도래한 분위기다.
여러 부분에서 전체적인 환경이 바뀌면서 PC가 아닌 다른 기기들과 특히 웹이 가능한 모바일 환경이라면 더욱 좋아하는 분위기다. 굳이 PC에서 모든 것을 해결하려 하지도 않고 그런 것에 대한 반감을 가지고 있다. 더욱 풍부해지는 모바일 기기, 콘솔 게임기, 동영상 재생용 PC, 뱅킹용 PC, 개인용 외장 RAID... 어찌보면 통합해도 될 것 같지만 가격대 성능비가 나날이 좋아지고 있는 시대라 PC 조차 한집에 두세대 혹은 개체수 별 한 대 인집들도 주변에 수두룩하다.

세번째는 최소화의 분위기다.
과거 작은 정부에서 큰 정부로, 여기서 다시 작은 정부로 가는 바람이 일고 있다.
OS의 분위기도 이와 같다. 작은 OS 그러나 강력한 OS를 원한다. 간편하게 깔고 발달한 서드파티들을 이용한 안티바이러스나이나 안티스파이웨어 등을 사용하고 표준화된 문서를 작성하는 OS와 어디서나 같게 보이는 브라우징 환경 그리고 웹 어플리케이션 등을 사용하는 것을 원한다. 편해지지만 강력해지고 개별 가격은 많이 내려가지면 개별적으로 필요에 의한 구매와 개별적인 유지보수 서비스를 받기를 원한다(패키지 구매가 아닌 연간라이센스 구매방식 등). 반면에 전문화된 프로그램은 자신이 원하는 OS에 맞는 것을 구비해서 사용하고 싶다는 의미다.

더이상 OS가 표준이 아니며 OS는 총괄적인 보고를 담당하고 어플간에 정확한 전달과 메모리 누수에 의한 보고를 정확하게 받고 등의 본연적인 작업에 더욱 충실해야 한다는 것이다.

개발자로써 닷넷프레임워크 및 실버라이트 등의 시도들이 모두 성공했으면 좋겠다. 정말 실버라이트 맵에 나와있는데로 OS 복속적인 이련의 작업들이 아니라 시대의 흐름과 패러다임에 맞는 본연적으로는 폐쇄적이지만 환경에 대해서는 개방적인 흐름을 포착하고 그에 걸맞는 OS 발표해 주기를 바란다는 것이다.

궁색한 변명은 제발 때려 쳤으면 좋겠다. 더욱 ~~해진 이라는 수식어들로 더이상 사람들을 현혹시키지말고 그냥 사람들을 빠져나가지 못하게 하는 것을 목적으로 하고 우리제품만 쓰도록 만들고 싶고 표준화는 MS를 따르는 것이고 모든 프로그램은 MS를 사용한다는 망상에서 벗어나 주셨으면 바란다.

그리고 결국 MS는 착각하고 있는 것 같다.
이것은 XP부터 가지고 있던 착각이다.
하나 컴퓨터를 여러사람들이 돌아가면서 사용한다는 것은 아주 우습고 번거로운 일이라는 것을...

WPF(Windows Presentation Foundation) : WPF는 윈도우 비스타의 UI처럼 화려한 화면 구현을 가능케 한다. 3D 화면뿐만 아니라 조작성을 포함한 애플리케이션의 사용 편의성을 개선할 수 있다. WPF와 관련해 마이크로소프트 익스프레션이 발표되었다. 이 제품을 사용하면 애플리케이션의 디자인과 개발을 완전하게 분리할 수 있게 된다. 결과적으로 디자이너가 제작한 이미지를 바탕으로 인터페이스나 조작성 구현이 가능해 개발자는 기능 개발에 주력할 수 있다.

WCF(Windows Communication Foundation) : WCF는 웹을 플랫폼화하는 기술이다. 구체적으로 서비스 지향 애플리케이션을 위한, 다양한 표준화 기술을 공통으로 사용하기 위한 클래스 라이브러리인 셈이다. WCF 적용시 서비스 이용자는 다양한 플랫폼에 분산되어 있는 서비스를, 통일된 방식으로 이용할 수 있다. 서비스 제공자도 이용자의 요구에 따라 각종 프로토콜이나 접속 규격에 대응할 수 있다.

WF(WIndows Workflow Foundation) : WF는 플로우 변화에 따른 유연성을 제공한다. 개개의 프로세스(프로그램)와 논리(워크플로우)를 분리시켜 상황 대처 능력이 뛰어난 시스템 구축을 돕는다.

WCS(WIndows CardSpace) : 마지막으로 WCS는 InfoCard로 불렸던 부분으로 다양한 암호화 토큰(사용자를 판별하는 기호, 사용자 이름이나 메일 주소 등)을 통합하고 동일한 인증 방식에서 인증되도록 하기 위한 도구이다. 실생활에서 카드로 물건 값을 지불하듯 다양한 사이트에 액세스할 수 있는 환경 구현이 가능하도록 한다.

XAML : XML의 일종으로 애플리케이션의 행동 등을 기술하기 위해 사용된다. WPF에서는 익스프레션으로 디자인된 내용이 XAML로 표현되어 닷넷 언어로 기술된 프로그램과 분리해 프로그램의 변경 없이 조작 편의성을 개선할 수 있다. WCF도 XAML가 사용된다. 통일화된 프로그래밍 방법으로 다양한 통신 수단에 대응할 수 있는 한편, 프로그램 변경 없이 통신 수단의 변화에 대응할 수 있다. 이 역시 XAML가 쓰인다. 예를 들어 XAML 기술 변경으로 프로그램의 개선 없이 HTTP에서 HTTPS(SSL)로 통신 수단을 바꿀 수가 있다.

WF에서는 워크플로우 기술에 XAML를 사용한다. 프로세스는 닷넷 언어로 기술된 프로그램이나 프로세스간의 관련 부분을 표현하는 워크플로우는 XAML로 기술된다. 워크플로우에 변화가 일어나더라도 프로그램은 변경 없이 유연하게 대응할 수 있다.

WCF와 WCS는 ‘표준’이라는 공통된 키워드가 있다. 2가지 의미가 있다. 다양한 통신 방식이나 인증 방식을 통일된 방식으로 사용할 수 있도록 한다는 의미에서의(사용자) 표준화라는 측면과 백그라운드에서 사용되는 기술이나 규격은 기존의 것을 이용한다는 점이다. 이에 따라 이용자, 개발자 모두에게 이익을 가져다주는 구조 설계가 가능하다.

닷넷 프레임워크 3.0은 혁신적인 사용 편의성을 구현하는 WPF, 서비스 지향 애플리케이션을 실현하는 WCF, 워크플로우·프로세스 제어를 실현하는 WF, 그리고 WCS 제공으로 닷넷 프레임워크 2.0상에서 구축된 시스템의 유연성과 확장성, 표준화를 앞당기는데 적잖은 역할을 할 것으로 기대된다.

최종 목표 - LAMP(Linux 2.6.x, Apache 2.2.x, MySQL 5.0.x, PHP 5.1.x) 환경 + Zend_Search_Lucene

ZSL

현재 적용해야할 사이트는 php 기반의 사이트다. 이 사이트는 인덱싱화에 있어서 아무런 문제는 없지만 너치와 연계하여 사용하는 것에는 무리가 따른다. 검색하여 인덱싱에 있어서 동기화의 작업이 복잡해 지거나 아예 시간에 따른 수동화로 하거나 검색 결과를 출력하는데 있어서도 사용자-php-jsp-php-사용자 라는 구조를 가지게 되므로써 사용에 따른 효율성만 떨어지게 된다.

그렇다면 해결점은 더 빠른 언어로 만들어진 웹 검색 가능한 솔루션 이거나 아니면 아예 php로 만들어진 루씬을 만드는 것이다. 전자에 있어서는 펄, 파이선, C#, C++로 만들어진 루씬이 있지만 너치와 같은 웹검색 솔루션은 없다. 그렇다면 후자인 php로 만드는 것인데 이는 더 큰 비용이 들기 때문에 php로 만들어진 루씬을 찾아보기로 했다. 찾아본 결과가 Zend_Search_Lucene이다.
Zend_Search_Lucene는 Zend 사의 Zend Framework의 포함된 하나의 검색 인터페이스다. Zend사는 php 관련 솔루션을 공급하는 회사로 대표적으로 php4 이상에 기본적으로 들어가있는 Zend Engine이다. 이 회사에서 Zend Platform을 내놓고 기반이되는 Zend Framework를 내놓았다. 최근에 웹기반개발이 확산 되면서 스크립트 언어들이 인정을 받고 대세인 시대가 되었다. 파이썬, Ajax, 루비 종류 등 다양하게 개발된 스크립트 언어가 나왔고 하나의 축으로 자리잡게 되었다. 허나 기존 php만으로도 구현 할 수 있기에 그 방법론으로 php 기반의 플랫폼을 내놓고 있고 이런 플랫폼은 벌써 10개도 넘는 것으로 안다.

http://www.phpriot.com/d/articles/php/search/zend-search-lucene/index.html 에서 Zend_Search_Lucene을 통한 검색 및 결과를 보여줬다.

1. 설치 환경
PHP 5.1.4 이상의 환경

2. Zend Framework
홈페이지에서 ZendFramework-0.8.0 다운 및 설치
php의 include_path 지정
사용 권한 등 변경

3. 테스트
간단한 indexing 파일 생성과 검색 결과에 대한 테스트 완료

남은 과제 아직 WebDB, crawling에 대해서는 php 실력이 부족한 관계로 차후에 시도해 보려함

참고사항;
ZendFramework-0.8.0
PHPUnit
Pear

이전 단계의 문제점을 해결하기 위해서는
우선 알아야 할 것이
1. 루씬은 TEXT 파일만 인덱싱 할 수 있다.
2. 루씬은 특정 사이트에 대해서 해석후 텍스트 파일로 만들 수 없다. (crawling)
3. 루씬은 특정 사이트의 하위페이지를 알아낼 수 없다. (WebDB)
4. 루씬은 웹용 검색 서블릿을 제공하지 않는다. (Servlet)

즉, 루씬은 컴퓨터 내에 특정 디렉토리(설정에 따라 그 하위도)내에 있는 TEXT 파일을 검색하여 내에 가지고 단어를 인덱싱화 하여 DB파일로 저장하고 질의를 통해서 그 결과를 알려줄 뿐 웹에서 사용할 검색엔진은 아니라는 것이다.
그렇다면 루씬의 인덱싱 파일화는 기본으로 가지고 세 가지의 문제점을 해결 할 것을 제공하면 되는 것이다.
이런 필요성 때문에 루씬을 기반으로 나온 프로젝트 중의 하나가 너치(Nutch)다.

너치는 Apache Tomcat 기반으로 돌아가는 웹 검색 엔진이다. crawling, WebDB에 대해 돌아가고 그에 더불어 Tomcat과 연계하여 검색 Servlet 페이지를 포함한다.

1. 너치 구동
Java 1.4.x 이상
Tomcat 4.x 이상

Tomcat 6.1 설치

2. 너치 설치
즉, 루씬은 컴퓨터 내에 특정 디렉토리(설정에 따라 그 하위도)내에 있는 TEXT 파일을 검색하여 내에 가지고 단어를 인덱싱화 하여 DB파일로 저장하고 질의를 통해서 그 결과를 알려줄 뿐 웹에서 사용할 검색엔진은 아니라는 것이다.
그렇다면 루씬의 인덱싱 파일화는 기본으로 가지고 세 가지의 문제점을 해결 할 것을 제공하면 되는 것이다.
이런 필요성 때문에 루씬을 기반으로 나온 프로젝트 중의 하나가 너치(Nutch)다.

너치는 Apache Tomcat 기반으로 돌아가는 웹 검색 엔진이다. crawling, WebDB에 대해 돌아가고 그에 더불어 Tomcat과 연계하여 검색 Servlet 페이지를 포함한다.

1. 너치 구동
Java 1.4.x 이상
Tomcat 4.x 이상

Tomcat 6.1 설치

2. 너치 설치
nutch-0.8.1 설치

3. 테스트
사내 사이트를 WebDB 및 인덱싱 화 완료
192.168.0.101:8080 에서 검색 결과 완료
(현재 tomcat 문제로 closed)

3. 테스트
사내 사이트를 WebDB 및 인덱싱 화 완료
192.168.0.101:8080 에서 검색 결과 완료

4. 문제점
사이트에 대한 기본적인 WebDB화 인덱싱 화에 대해서는 문제가 없지만 가장 큰 문제는 JVM 하에서 사용할 수 있다는 것이다.

최종 목표 - LAMP(Linux 2.6.x, Apache 2.2.x, MySQL 5.0.x, PHP 5.1.x) 환경 + Lucene+ Nutch

淚信? 淚神?

1. 리눅스를 깔자
CENT OS 4.4 설치

2. 자바 개발 환경을 만들자
기본적으로 gcj(gcc에 포함된 jre 기능을 하는 것)가 자꾸 방해를 한다.
JDK 1.4 혹은 1.5, 그 이후 버전으로 변경 하고 gcj 등이 관련된 심볼릭 링크들을 정리
/etc/profile에 JAVA_HOME 및 jar 파일 등을 PATH, CLASSPATH 에 추가
JUnit 4.1 설치 (배포버전)
/etc/profile에 JUNIT_HOME 및 jar 파일 등을 CLASSPATH 에 추가
Ant 1.6.2 혹은 그 이후 버전 (src 빌드)
/etc/profile에 ANT_HOME 및 jar 파일 등을 CLASSPATH 에 추가
Javacc 4.0 설치 (src 빌드)
/etc/profile에 JAVACC_HOME 및 jar 파일 등을 CLASSPATH 에 추가
Lucene 2.1.0 (배포버전)
/etc/profile에 LUCENE_HOME 및 jar 파일 등을 CLASSPATH 에 추가
- src 버전으로 ant를 이용하여 빌드를 해봤으나 2.1.1-dev 버전이 생기는 탓으로 찜찜한 기분에 배포버전을 사용하기로 함

3. 테스트
test를 위한 jar 파일을 CLASSPATH에 등록하고
java org.apache.lucene.demo.IndexFiles {full-path-to-lucene}/src 등을 수행 완료
java org.apache.lucene.demo.SearchFiles 검색 완료

4. 남은 문제들
쉘에서 cl 모드로 인덱스 생성 및 질의를 통한 검색은 문제없이 되었으나 실질적인 문제는 웹을 통하여 문서에 대한 url 값을 가져오는 것이 문제였다.

0. 들어가기 전에
 Microsoft(이하 MS)에서 Windows XP(이하 XP) 및 SP2를 발표하면서 개발자 및 (윈도우 서버)관리자 중심으로 세미나를 하였지만 이번에 Windows Vista(이하 비스타)를 발표하면서 하는 세미나들에 비하면 횟수나 질로 보나 낮았다. 이런 아주 눈에 보이는 단순한 사실에 근거하여 말하는 것도 좀 우습지만 MS가 이번 비스타에 대해서 얼마나 많은 것을 걸고 있고 그에 대한 반대급부에 대해서 민감한지가 느껴질 정도다. 과거 MS-DOS에서 Windows 환경으로 그리고 Win16(Windows 95, 98 및 SE)에서 Win32(Windows XP) 환경으로 넘어 오면서 약간은 위에서 아래를 내려다 보는 시선으로 사용자들을 대한 감이 있었는데 이번 비스타에 대해서는 오히려 눈치를 보고 있다고 할 수 있다. 왜 그런 것인가 나름대로 정리한 생각은 MS는 XP SP2를 발표하면서 데스크탑 OS에 대한 생각을 고쳐 먹었다. 또한 약간은 몇 차례 있어왔던 인터넷 대란에 대해서 어느 정도 책임에 대해 적극적이지는 않지만 소극적인 반응의 결과로 변화를 시도하고 있다고 보고 있다. 세미나에서 강사가 한마디로 요약해서 해준 말을 인용하자면 이전의 MS는 데스크탑 OS는 모든 것을 열어두고 문제가 생기면 막자 주의였다. 모든 사용자들은 기본적으로 Administrators의 권한으로 OS를 사용하게 된다. 그렇기 때문에 발생한 문제가 잘 모르는 사람들의 드라이버설치, 인터넷이나 메일에 의한 감염에 그대로 방치하는 것이 었다. 그 결과 이상한 공식이 나왔는데 'Windows는 불안하다'라는 것이다. 어디선가 본 이야기로는 윈도우에서 블루스크린을 보게되는 현상의 대부분은 윈도우 자체 결함이 아닌 같이 사용된 드라이버의 문제라고 한 글을 본적이 있다. MS를 대변하는 의미로 적기 보다는 그 만큼 많은 영역을 소화하기 위해서는 '일반적인 사용자들'은 사용자 권한으로 행동을 취하게 해야 하는 것이 OS로서 책임을 지는 것이라는 것을 이제야 비스타에서 적용한다는 것이다.
 그럼 비스타에서 바뀐 것은 무엇인가 사용자들은 왜 비스타를 설치하는 되는 것이 없더라, 불편해서 못써먹겠네 등의 말을 하는 것일까. UAC, 보호모드, 가상화, 보안 정책 등등을 들어서 설명할 수도 있겠지만 그런 것은 이미 세미나에서 지겹도록 들었기 때문에 그냥 정리된 내용을 적기로 하였다. 그간 우리는 올바른 철학을 적용하여 설계한 OS 사용했기 보다는 어찌 보면 우리나라 IT에 맞는 철학에 입각하여 만들어진 것이라고 느껴지는 OS를 사용하다가 갑자기 표준이라는 것을 어느 정도 적용시킨 OS를 사용하다 보니 나오는 말이라고 할 수 있다. 안전한 = 편한 이라는 공식이 적용 될 수 있는 사례는 거의 없다. 안전하다는 것은 적어도 한번이라도 더 불편함을 초래하고 마는 것이다. 하지만 그것으로 갑자기 불편함을 감수해라 라는 의미로 말하는 것인가? 그것은 아니라고 본다. 개발환경, 플랫폼, 워크프레임 등의 기반이 바뀐다는 것은 단지 프로그램의 버전이 올라가서 바뀌는 것을 적응하는 보다 많은 부분에서 사용자의 생각이 바뀌어야 한다는 것을 의미한다. 리눅스의 그놈을 사용하면서 윈도우는 이랬는데 하면서 차이점을 지적하여 사용 못해먹겠다는 자세보다는 이런 것이 리눅스와 윈도우의 차이점이고 이렇게 만든 이유는 무엇인가 있겠구나 하는 자세가 필요하다는 것이다. 다음으로 그에 합당한 프로그램을 만들어야 하는데 아직 그런 것들을 생산할 만큼의 충분한 시간적 여유가 없었다는 것을 의미한다. 즉, 전체적인 환경이 숙성될 만한 시간이 부족한데 궁여지책으로 사용해야 한다는 것이다. 전압으로 예를 들면(비약이 큰 것을 염두하자) 110V에서 어느날 갑자기 220V로 바꿨다고 한다면 110V에서 사용하던 기기들은 어떻게 될까? 당연히 트랜스(변압기)를 사용하여 사용하여야 한다. 하지만 언제까지 그렇게 사용하지 않는다. 신제품이 나온다면 그에 맞는 220V로 나오게 되고 사람들은 슬슬 트랜스를 이용한 110V 기구 사용대신에 진짜 220V 제품을 쓰게 되고 그 비율은 점차 확대되는 것이다. 이처럼 현재(혹은 과거) 기술을 비스타라는 새로운 환경에 적용시켜서 해내라는 것 보다는 새로운 환경이 적용된 프로그램으로 옮겨가는 것을 바라는 것이 더 올바르다. 하지만 비스타는 Win32의 무서운 갈굼을 계속 받아 사용자들에게 새로운 환경을 경험시키는데 만족할 것이고 이 후 차세대 에서 완벽하게 적용된 OS가 발표되고 사용자들은 현재보다 훨씬 수월하게 다른 환경으로 옮겨갈 것이다.

들은 세미나는 다음과 같았다.
1. Windows Vista에서의 ActiveX 컨트롤
 세미나의 핵심은 윈도우의 변화 과정(XP -> XP SP2 -> XP SP2 + IE7 -> 비스타)을 파악해야 하고 그에 따른 과거의 기술을 어떻게 사용할 수 있을까를 예를 들어서 설명하였다. 전체적으로 예시 보다는 바뀐 비스타와 XP의 차이점을 요약 및 정리 해 주었고, 우리나라는 왜 ActiveX를 사용하게 되었는가에 대해서도 까칠하게 짚고 넘어갔다. 역시나 현 전체적인 IT 업계와 개발 트렌드를 파악하여 과거 기술을 재사용하는 것에 집착하는 것 보다 새로운 플랫폼을 파악해 과거 기술을 전이시킬까를 고민하자고 하였다.

2. Windows Vista 보안에 맞는 Application 개발
 세미나의 핵심은 매니지드 코딩(Managed Coding)을 하자. 앞서 세미나들과 전체적으로 곂치는 내용이었지만 핵심을 잘 요약해 주고 강사님이 입심도 좋으셔서(이빨까기 유명함 -_-) 가장 재미있는 세미나 같았다. 그리고 현재 개발 트렌드인 전체를 배포하는 것이 아니라 환경이 배포되고 그에 맞는 콘텐트들을 배포하는 방식(예를 들면 플래시 플레이어 - 기반의 프로그램들)을 택하고 윈도우도 그 작업을 이미 시작했으니 어서 빡시게 공부하자라는 내용이었다.

SYMPTOMS

MSI (s) (BA:AD) [12:00:00:000]: SOFTWARE RESTRICTION POLICY: Verifying object --> 'D:\WINDOWS\Installer\50baad.msp' against software restriction policy
MSI (s) (BA:AD) [12:00:00:000]: SOFTWARE RESTRICTION POLICY: D:\WINDOWS\Installer\50baad.msp has a digital signature
MSI (s) (BA:AD) [12:00:00:000]: SOFTWARE RESTRICTION POLICY: SaferIdentifyLevel reported failure. Assuming untrusted. . . (GetLastError returned 5)
MSI (s) (BA:AD) [12:00:00:000]: The installation of D:\WINDOWS\Installer

출처 : http://netez.com/2xExplorer/shellFAQ/bas_xplore2.html

There are no two ways about it, using low-level COM to enumerate folders is quirky. Note that I didn't say "difficult", it just takes some time getting used to it. With COM you have to manage objects yourself: create the right one, ask for a specific interface for the functionality you are after, then use it and finally take care to release it. In contrast, in regular API-based programming the operating system is doing the management for you; you just call functions directly, oblivious about objects and things behind the scenes.

To enumerate a folder via COM, you need an IShellFolder pointer to the folder object you're after. We've seen a sketch of how to obtain this interface by parsing a path name in the previous section. The next step is to ask the object to enumerate itself using its EnumObjects method, which creates a new object which exposes an IEnumIDList interface. This enumerator object has the contents we are after, as a collection of local PIDLs, one for each item in the folder.

The best way to illustrate all this is with an example. Let's try to create the COM-equivalent of the EnumerateFolderFS() sample presented earlier, which read the contents of a filesystem folder given a full path to it. The following EnumerateFolder() sample produces the same results in a completely different approach.

#include <shlobj.h>

void EnumerateFolder(LPCTSTR path)
{
   HRESULT hr; // COM result, you'd better examine it in your code!
   hr = CoInitialize(NULL); // initialize COM
   // NOTE: usually COM would be initialized just once in your main()

   LPMALLOC pMalloc = NULL; // memory manager, for freeing up PIDLs
   hr = SHGetMalloc(&pMalloc);

   LPSHELLFOLDER psfDesktop = NULL; // namespace root for parsing the path
   hr = SHGetDesktopFolder(&psfDesktop);

   // IShellFolder::ParseDisplayName requires the path name in Unicode.
   OLECHAR olePath[MAX_PATH]; // wide-char version of path name
   MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, path, -1, olePath, MAX_PATH);

   // parse path for absolute PIDL, and connect to target folder
   LPITEMIDLIST pidl = NULL; // general purpose
   hr = psfDesktop->ParseDisplayName(NULL, NULL, olePath, NULL, &pidl, NULL);
   LPSHELLFOLDER psfFolder = NULL;
   hr = psfDesktop->BindToObject(pidl, NULL, IID_IShellFolder, 
                                 (void**)&psfFolder);
   psfDesktop->Release(); // no longer required
   pMalloc->Free(pidl);

   LPENUMIDLIST penumIDL = NULL; // IEnumIDList interface for reading contents
   hr = psfFolder->EnumObjects(NULL, SHCONTF_FOLDERS | SHCONTF_NONFOLDERS, 
                               &penumIDL);
   while(1) {
      // retrieve a copy of next local item ID list
      hr = penumIDL->Next(1, &pidl, NULL);
      if(hr == NOERROR) {
         WIN32_FIND_DATA ffd; // let's cheat a bit :)
         hr = SHGetDataFromIDList(psfFolder, pidl, SHGDFIL_FINDDATA, &ffd, 
                                  sizeof(WIN32_FIND_DATA));

         cout << "Name = " << ffd.cFileName << endl;
         cout << "Type = " << ( (ffd.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY)
                                ? "dir\n" : "file\n" );
         cout << "Size = " << ffd.nFileSizeLow << endl;
         
         pMalloc->Free(pidl);
      }
      // the expected "error" is S_FALSE, when the list is finished
      else break;
   }

   // release all remaining interface pointers
   penumIDL->Release();
   psfFolder->Release();
   pMalloc->Release();

   CoUninitialize(); // shut down COM
}

Oh dear, that sure was hard work. 56 lines of code to do exactly the same thing EnumerateFolderFS() managed in just 23 lines — less than half. But hey, that's C++ baby, either take it or leave it and join the VB club <g>. Since this is the first real COM example I presented, I'll try to be gentle and explain it thoroughly. Many typical issues in COM programming appear in this code:

• COM initialization. Before you use any of the COM services and objects you need to call CoInitialize. Conversely, after you're done with COM you must call CoUninitialize. Typically an application that relies heavily on COM will initialize the subsystem just once when it starts, not inside each function that utilizes COM. Still it's no harm calling CoInitialize more than once, as long as it is balanced by a CoUninitialize.
  ADVANCED. If your program is multi-threaded, then COM must be initialized in each thread that uses its services. Initializing it once in the main thread won't be enough.
• Object management. The code sample used four distinct COM objects to read the folder contents. Using desktop's IShellFolder the path was parsed, generating a pidl to the target folder. This second object was created using desktop's BindToObject. The enumerator (third object, the one we were after all along) was created by EnumObjects. Finally the shell memory manager was created by SHGetMalloc to free the various PIDLs that were allocated for us. All COM objects are dynamically created and must be released to free up the associated memory and resources via the object's Release method, inherited from IUnknown. Note that PIDLs are not objects, only pointers to allocated memory. That's why they are Free'd and not Release'd, something that took me some time to realise in the early dayz.
• UNICODE strings. In case you haven't heard about them, UNICODE strings have wide characters, i.e. 2-bytes each. Apparently the orientals are responsible for this major upset <g>. COM has adopted the UNICODE system whole-heartedly, and most system (and shell) objects expect strings to be wide. The problem is that windows 95/98 (dunno about Me) work with multibyte strings, which are basically regular single-byte strings, despite what their name suggests. If you want your proggy to work in all windows platforms then you'd have to stick with single-byte strings and do manual conversions whenever a wide string is required. That is exactly what MultiByteToWideChar function does above. If you use MFC, you can take advantage the CString class, which simplifies string management and conversions. The drawback is the performance penalty involved for all these conversions; unfortunately there's no way around it, except if you are willing to distribute separate ANSI and UNICODE versions of your programs.
• Enumerators. These fancy-name objects are frequent denizens of the COM landscape. Any VB people in the audience will be familiar with the term collections. Enumerators are simple objects that hold collections of similar items. The internal organization is transparent; enumerators expose an IEnumxxx interface, as IEnumIDList. Once initialized, items can be accessed sequentially by calling the Next method repeatedly, until some error indicates that the list is exhausted. Personally I feel it's a grand omission that all those objects don't have a method like Count to give the total number of elements in the list. An important detail is that enumerators usually return duplicates of their listed items which you are responsible to cleanup. In the code sample above note that each pidl is Free'd after use.

You can now appreciate why people say that COM is a technology with a steep learning curve. One has to be familiar with dozens of details before even the simplest "Hello COM" program can be build. And you'd better hurry in that climbing while learning, because mikro$oft have already prepared the COM+ mountain for you to climb next, slippery slopes an'all. Will this torment ever end? <g>

Of course, these issues are all for starters. The main dish is learning about all the COM objects supplied by the framework, finding out what they can do for you, and how to work with them, what interfaces they support, etc. The online documentation is guaranteed to be the most complete and up-to-date source of reference information. As they say, if you don't like reading, probably software development is not your ideal vocation. What you read in that good book published in 1998 may already be obsolete, plus there will be dozens of new objects introduced since then.

Ok, but what about that namespace exploring?

Sorry folks, I got a bit carried away there. So, let's get back to the subject, folder contents enumeration. The EnumerateFolder() sample will produce almost the same results as a the filesystem version EnumerateFolderFS(). Even the order of the items is the same, which hints that EnumObjects down deep must be using FindFirstFile et al for doing the actual folder reading. But almost the same implies there are some differences:

• We no longer read the '.' and '..' pseudo-items. That's progress since I consider these two plain nuisances. <g>
• We don't get automatic filename filtering; the best we can do is specify whether we want files, folders or both, via the SHCONTF_FOLDERS and SHCONTF_NONFOLDERS flags that EnumObjects understands.

The most important difference however, is the file date/time information. SHGetDataFromIDList doesn't fill in the file details in WIN32_FIND_DATA as thoroughly as an equivalent FindFirstFile would. Only the modification date is filled in, and even that is rounded to the nearest even second. That's the reason why I mentioned that you need both COM and traditional API to obtain complete information for filesystem folders.

How To Convert a File Path to an ITEMIDLIST

   LPITEMIDLIST  pidl;
   LPSHELLFOLDER pDesktopFolder;
   char          szPath[MAX_PATH];
   OLECHAR       olePath[MAX_PATH];
   ULONG         chEaten;
   ULONG         dwAttributes;
   HRESULT       hr;

   // 
   // Get the path to the file we need to convert.
   // 
   GetCurrentDirectory(MAX_PATH, szPath);
   lstrcat(szPath, "\\readme.txt");

   // 
   // Get a pointer to the Desktop's IShellFolder interface.
   // 
   if (SUCCEEDED(SHGetDesktopFolder(&pDesktopFolder)))
   {
       // 
       // IShellFolder::ParseDisplayName requires the file name be in
       // Unicode.
       // 
       MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, szPath, -1,
                           olePath, MAX_PATH);

       // 
       // Convert the path to an ITEMIDLIST.
       // 
       hr = pDesktopFolder->lpVtbl->ParseDisplayName(pDesktopFolder,
                                                     NULL,
                                                     NULL,
                                                     olePath,
                                                     &chEaten,
                                                     &pidl,
                                                     &dwAttributes);
       if (FAILED(hr))
       {
           // Handle error.
       }

       // 
       // pidl now contains a pointer to an ITEMIDLIST for .\readme.txt.
       // This ITEMIDLIST needs to be freed using the IMalloc allocator
       // returned from SHGetMalloc().
       // 

       //release the desktop folder object
         pDesktopFolder->lpVtbl->Release();
   }
				

This library simplifies management of Windows Shell ITEMIDLISTs (further PIDLs). For me, it always has been trouble to keep track of all allocated PIDLs and to free them in time. So, I wrote this library.

As time goes, the library has became rather messy (it's because I put there all PIDL-related functions that may be reusable). But it still helps me a lot.

The core of this library is CPidl class. All other functions exported here are mostly supplemental.

Constructors

CPidl::CPidl()

Constructs empty CPidl instance

CPidl::CPidl(LPITEMIDLIST other)

Constructs CPidl instance and attaches (not copies) ITEMIDLIST allocated somewhere else. At destruction time attached ITEMIDLIST will be deallocated.

CPidl::CPidl(const CPidl& other)

Copy constructor. Copies one instance of CPidl into another.

CPidl::CPidl(LPCTSTR pszPath)

Constructs CPidl instance from file or folder path. In case of error, the PIDL will be empty. It uses IShellFolder::ParseDisplayName() for getting PIDL.

CPidl::CPidl(int nSpecialFolder)

Constructs CPidl instance from special folder ID. (See CSIDL_XXX constants in MSDN).

Member functions

LPITEMIDLIST CPidl::Detach()

Detaches contained PIDL from wrapper

LPITEMIDLIST CPidl::Copy()

returns a copy of contained PIDL

void CPidl::Free()

frees contained PIDL. This member function is called automatically at destruction time.

CPidl::operator bool()

conversion operator for using in boolean expressions. Will return true if contained PIDL is not NULL

CPidl::operator LPITEMIDLIST()

Useful conversion operator that allows to use CPidlas a function argument in place of LPITEMIDLIST

CPidl::operator LPITEMIDLIST*()

CPidl::operator LPCITEMIDLIST*()

Useful conversion operator that allows to use CPidl as a function argument in place of LPITEMIDLIST*. Usually the pointer to LPITEMIDLIST is used to receive when a PIDL from function. Make sure you call CPidl::Free() before using CPidl instance for receiving PIDLs!

CPidl& CPidl::operator=(LPITEMIDLIST other)

CPidl& CPidl::operator=(const CPidl& other)

Assignment operators

Global functions

IShellFolderPtr& GetDesktopFolder()

returns a reference to static instance of IShellFolder interface for root namespace folder.

IMallocPtr& GetMalloc()

returns a reference to static instance of IMalloc interface. This interface is essential for working with PIDLs.

int GetItemIDSize(LPCITEMIDLIST pidl)

returns PIDL size in bytes.

int GetItemIDCount(LPCITEMIDLIST pidl)

returns number of elements in PIDL. If you don't know what does it mean, reread "Working with Item ID Lists" article in MSDN.

LPBYTE GetItemIDPos(LPCITEMIDLIST pidl, int nPos)

gets pointer to nPos'th element in PIDL or NULL if nPos exceeds number of elements in PIDL.

LPITEMIDLIST CopyItemID(LPCITEMIDLIST pidl, int cb=-1)

makes a copy of PIDL. cb specifies number of bytes to copy. If it's equal -1, entire PIDL will be copied.

LPITEMIDLIST MergeItemID(LPCITEMIDLIST pidl,...)

Merges two or more PIDLs (usually relative ones) into absolute (or fully-qualified) PIDL. The programmer should know what he's doing when he calls this function :-). Typical usage is to make fully-qualified PIDL from folder PIDL and PIDL returned by IShellFolder::EnumObjects()

int CompareItemID(LPCITEMIDLIST pidl1,LPCITEMIDLIST pidl2)

int CompareItemID(LPCITEMIDLIST pidl1,int nSpecialFolder)

int CompareItemID(int nSpecialFolder,LPCITEMIDLIST pidl2)

Compares two PIDLs. Returns 0 if equal and -1 otherwise.

LPITEMIDLIST GetItemIDFromPath(LPCTSTR pszPath)

returns PIDL for file or folder name. Or NULL if error

HRESULT SHBindToParent(LPCITEMIDLIST pidl, REFIID riid, VOID **ppv, LPCITEMIDLIST *ppidlLast)

Closely resembles standard shell function SHBindToParent(). It was neccessary to write it becuase it's not available on Windows 95/NT. Refer to MSDN for arguments description.

BOOL TrackItemIDContextMenu(LPCITEMIDLIST pidlShellItem, UINT nFlags, LPPOINT ptPoint, HWND hWnd)

BOOL TrackItemIDContextMenu(LPCTSTR pszShellItemPath, UINT nFlags, LPPOINT ptPoint, HWND hWnd)

This function builds, shows and tracks shell context menu for PIDL or or file/folder path. It returns TRUE if user clicked on some context menu item. In case of error or if user didn't choose anything from menu it returns FALSE.

• LPCITEMIDLIST pidlShellItem, LPCTSTR pszShellItemPath: a PIDL or path name of the shell item to show context menu for.
• UINT nFlags: a set of TPM_XXX flags. See function TrackPopupMenu() for description
• LPPOINT ptPoint: a point in screen coordinates where menu should appear.
• HWND hWnd: a handle to the window - owner of the menu. It cannot be NULL

쉘을 다루는데 있어서 애로사항이 꽃피는 경우가 파다한데 그나마 쉽게 접근 할 수 있는 클래스

출처 : http://tunelinux.pe.kr/gboard/bbs/board.php?bo_table=tip&wr_id=75&page=

RHN 에 지식기반정보가 있습니다.
rhn 등록되어있는 사용자만이 접속할 수 있지요.

한번 테스팅해볼만한 내용이네요.
문제해결을 위하여.

그리고 시스템의 정보를 수집하기 위한 sysreport 라는 프로그램이 있습니다. rhn등을 이용하여 설치하면 되고 위 명령만 치면 시스템의 주요정보를 모읍니다.

Solution Found
Issue:
My system had a kernel panic, an oops message, or is freezing for no apparent reason. How can I find out what is causing this?
Resolution:         Last update: 08-17-04
Resolving a kernel panic or a kernel oops is not a simple task. First off, in order for Red Hat to understand the cause of this, we will need to see the panic or oops message in its entirety. Below you will find our \"Profiling\" document, it contains the information that Red Hat requires in order to best troubleshoot a kernel panic or kernel oops related to a system crash.

We do recommend that you are running the latest kernel available for your release version and that have your system completely updated.

To further debug this problem we will need the following information:
The output from the following commands:

    * sysreport
    * lspci -vv
    * lsmod
    * cat /proc/meminfo
    * cat /proc/cpuinfo
    * uname -a

Please note, sysreport is an application that may not be installed on your system. If you do not have it installed, please install the sysreport RPM in one of the following ways:

    * Run: up2date sysreport if your system is registered with RHN, this will download and install the package for you.
    * Locate the sysreport package on your installation CD's and install the package with: rpm -ivh sysreport-version#.rpm - where version# will match the files version number on your installation CD.

If possible, please run these commands when the slow down is occuring, or as close as possible to a reproduceable crash. That being said, we do recognize that this is not always possible, but the information is still needed.

    * OOPS messages:

      If your machine crashes with an OOPS message, similar to the following:

Unable to handle kernel NULL pointer dereference at virtual address
00000018
*pde = 0f992001
Oops: 0000
CPU:    1
EIP:    0010:[]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010207
eax: 00000000   ebx: c87a1ed0   ecx: c02de5e0   edx: f3de3b00
esi: c87a1eb4   edi: 00000000   ebp: 00000007   esp: c3f5bfa0
ds: 0018   es: 0018   ss: 0018
Process kswapd (pid: 11, stackpage=c3f5b000)
Stack: 00000000 fffffe5d 00000245 00085992 00000001 00000000 000000c0 000000c0
       0008e000 c0136c51 000000c0 00000000 c3f5a000 00000006 c0136ce5 000000c0
       00000000 00010f00 c3ff1fb8 c0105000 c0105866 00000000 c0136c90 c02f5fc0
Call Trace: [] do_try_to_free_pages [kernel] 0x11
[] kswapd [kernel] 0x55
[] stext [kernel] 0x0
[] kernel_thread [kernel] 0x26
[] kswapd [kernel] 0x0
Code: f7 40 18 06 00 00 00 75 f0 8b 40 28 39 d0 75 f0 31 d2 85 d2

>>EIP; c0136177    <=====

Trace; c0136c51
Trace; c0136ce5
Trace; c0105000 <_stext+0/0>
Trace; c0105866
Trace; c0136c90
Code;  c0136177
00000000 <_EIP>:
Code;  c0136177    <=====
   0:   f7 40 18 06 00 00 00      testl  $0x6,0x18(%eax)   <=====
Code;  c013617e
   7:   75 f0                     jne    fffffff9 <_EIP+0xfffffff9>
c0136170
Code;  c0136180
   9:   8b 40 28                  mov    0x28(%eax),%eax
Code;  c0136183
   c:   39 d0                     cmp    %edx,%eax
Code;  c0136185
   e:   75 f0                     jne    0 <_EIP>
Code;  c0136187
  10:   31 d2                     xor    %edx,%edx
Code;  c0136189
  12:   85 d2                     test   %edx,%edx

      We will need the full output from the OOPS message, which can be obtained in one of the following ways:

          o Copied down by hand (or from a digital picture), please remember we need the complete message and that this may sometimes be the only way to get the oops message.
          o Setting up a serial console to capture the message. This can be accomplished by connecting a null modem cable to the serial port of the machine and adding:

            console=ttyS0,115200 console=tty0

            to either the kernel line of grub or in an \"append=\" statement for lilo. Once this is done, on the other machine the null modem is attached to, run a terminal emulator such as \"minicom\" (linux) or \"hyperterminal\" (windows).

    * Mysterious Hangs, Freezes and Slowdowns:

      For hangs and freezes, we would like you to capture some information by enabling the sysrq key. This can be enabled by editing the file /etc/sysctl.conf and changing the line to read:

      kernel.sysrq = 1

      Enable it immediately by saving the file and running:

      # sysctl -p

      Once this is enabled, we will need the output from the following key combinations:
          o alt-sysrq-t
          o alt-sysrq-p
          o alt-sysrq-m
      * Please note that sysrq is the PrintScreen key.

      Please run alt-sysrq-p multiple times so that we can be sure to get output from all CPUs on the machine. Also, run alt-sysrq-m last as it has a possiblity of locking the box up harder then it already is. You may wish to use a serial console to capture the information. You will also want to ensure that we have at least 1 alt-sysrq-p from each CPU, denoted by a CPU: # line in the output. Note the first CPU is number 0.

    * Slowdowns:

      For general slowdowns we will first need to know the following:
          o What kind of load is the box under?
          o Are you running anything to produce this load?
          o If you stop running whatever may cause the load, does the slowness immediately go away?

            Next, we would like you to follow the following steps to gather some data for our engineers:

            1. Enable kernel profiling by turning on nmi_watchdog and allocating the kernel profile buffer. For example, add the following two items to the \"kernel\" line of /boot/grub/grub.conf (using grub):

                  profile=2 nmi_watchdog=1

            as in the following example:

                  kernel /vmlinuz-2.4.9-e.27smp ro profile=2 nmi_watchdog=1

            If using LILO, add the following to the global section (before the first image= line) of lilo.conf:
                  append=\"profile=2 nmi_watchdog=1\"
            and run lilo -v as root.
            Now you should be able to reboot.

            2. Create a shell script containing the following lines:

#!/bin/sh
while /bin/true; do
  echo;date
  /usr/sbin/readprofile -v -m /boot/System.map | sort -nr +2 | head -15
  /usr/sbin/readprofile -r
  sleep 5
done

          o Make the system demonstrate the aberrant behavior.
          o Run the following three commands simultaneously:

                  Execute the readprofile shell script above, redirecting its output to a file.
                  Execute vmstat 5 and redirect its output to a second file.
                  Execute top -d5 and redirect its output to a third file.

          o Attach the output files (preferably in gzip'd tar file format) to a web ticket that either you or a Red Hat Engineer has opened.

      You can open a web ticket with Red Hat support by logging into your www.redhat.com account in the Support and Docs section and selecting the Web Support button located under the \"Active Support Entitlements\" section.