공룡호가 사는 세상 이야기

패키지를 깔려고 하는데 이상한 에러가 발생한다. 왠 황당한 경우인지?
기본적으로 패키지를 설치하기 위해서는 /var/sadm/install/admin/default 파일이 존재해야 한다. 이 파일은 패키지 설치에 관련된 파라미터들이 기술되어 있는 파일인데, 이 파일이 없거나 손상되었을 경우, 패키지가 올바로 설치될 수 없어서 오류가 발생한다.

해결은 간단하다. 위 경로에 default 파일을 생성하고 다음 내용을 복사해서 붙여넣자. 그리고 다시 pkgadd ~~~
확인결과 solaris9/10은 파일 내용이 동일하다. 상관 없다.

#
# Copyright 2003 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
#ident  "@(#)default    1.5     03/06/11 SMI"
#
mail=
instance=unique
partial=ask
runlevel=ask
idepend=ask
rdepend=ask
space=ask
setuid=ask
conflict=ask
action=ask
networktimeout=60
networkretries=3
authentication=quit
keystore=/var/sadm/security
proxy=
basedir=default

덧붙여 여기까지 본 김에 한가지 을 배워보자.
자세히 보면, 이 default 라는 파일은 package를 install 할 때의 파라미터들이라고 앞서 설명했다.
눈치 빠르신 분들은 대충 아시겠지만, 각종 파라미터들이 ask로 되어 있는 것을 보아하니, 패키지를 설치하다 충돌이 나거나 하는 기타 여러가지 사항에 대해서 interactive하게 설치를 하기 위함을 알 수 있다.
그럼, ask 를 뭔가로 대신하면 package를 원샷에 설치할 수 있다는 말이 된다.
ask를 모두 nocheck로 변경한다. basedir은 package의 설치 위치를 변경해 줄 수 있다. 그럼, 원샷에 설치할 수 있는 준비가 모두 되었다.

그런데, 여기서 또 하나 문제가 있다. Non-Interactive하게 설치하도록 변경하였는데, Interactive하게 설치해야 하는 상황이 되면, 그 때 마다, nocheck를 ask로 변경해야 한단 말인가? -_-
솔라리스가 그렇게 허접할리가 없다. 위에서 편집한 파일을 저장을 default로 하지 말고 non으로 하여 저장하자.(반드시 non일 필요는 없다.)
그리고 다음과 같이 명령어에 옵션을 주자.

# pkgadd -na non -d pkgfile [pkgname]
ex) # pkgadd -na ./non -d beautifulpkg all

조금 전에 nocheck로 설정한 파일을 이용하여 패키지를 설치하는 것을 확인할 수 있다.
검색해서 이 문서를 보신 분들은, 문제도 해결하고, 패키지도 잘 설치하셨을 것이고, 팁도 하나 배우셨고. ~~
오늘은 그만하고 퇴근들 하십쇼~ ^^




'유닉스' 카테고리의 다른 글

ZFS manual  (0) 2009.01.05
Solaris Disksuite simple manual  (0) 2008.11.24
SSH setting for solaris8  (0) 2008.08.26
Fixing read-only file system error  (0) 2008.08.13
Solaris10 sd.conf 동적으로 다시 읽기  (0) 2008.05.26

사용자 삽입 이미지
앞서 리뷰했던 메모리 관련 Article과 관련 있는 기사를 한번 더 보고자 한다.
프로그래밍에서 메모리 결함은 대부분 잘못된 코딩 습관에서 온다고 언급했었다.
사실, 메모리 결함 뿐 만이 아니다. 모든 오류나 결함은 마찬가지이다.
같은 맥락에서, 이번 Article을 읽다가 인상 깊은 구절을 발견했다.
C 프로그램에서 컴파일 옵션에 -O -Wall -W -Wshadow -pedantic을 사용하면, 소스코드에서 올바르지 않거나 의심스러운 부분진단 메시지로 날려준다.

많은 개발팀이 컴파일러가 제공하는 진단 결함을 불치병이나 세금처럼 필요악으로 취급한다.

내 경험으로는 아무리 잘 관리해도 진단 메시지를 무시하는 50만 줄짜리 프로젝트는 오류가 적어도 5000개 정도 존재한다. 물론, 그 중 적어도 몇 개 정도는 자주 발생하는 오류로 드러난다. 결코 음수가 되지 않는 unsigned 정수를 조건으로 사용하거나, 선언한 변수에 철자 오류가 있어 전혀 사용되지 않는 경우 등이다. 모든 컴파일러 진단 메시지를 하나씩 없애가는 과정에서 코드 품질은 극적으로 향상된다. 컴파일러 진단 메시지는 자동화하기가 쉬우므로 비용도 적게 든다

사실, 그렇지 않은가 Error는 수정하지 않으면, 컴파일을 할 수 없으므로 어쩔 수 없이 하게 되지만, Warnning은 그냥 지나치기 일쑤다. 지나치다 보면 이제 손대기 귀찮고 짜증날 정도로 많아지게 되고, 나중엔 아예 손을 쓰기조차 어려워진다. 그래도 컴파일은 된다. 기대하는 대로 작동한다. 하지만 오류는 언제나 잠재 해 있다는 것이 문제이다.

메모리 오류에 한정되어 있지만, 이는 굉장히 중요한 문제이다.
컴파일 옵션을 주어 모든 진단 메시지를 확인하고 그에 따른 진단 과정을 살펴보면서, 올바른 코딩 습관에 대해 다시 한번 더 생각 할 기회와 메모리 오류에 대해 진단하고 해결하는 과정도 함께 익힐 수 있을 것 같다. 코드 품질을 극적으로 높이는 관건은 기술적 혁신이 아니라 문화적인 혁신이다. 맞는 말이다.



메모리 오류
때문에 고생한 적이 한 두번이 아니다. Syntax 오류가 아니라서 더더욱 잡아내기 힘들고, 특수한 상황 설정을 해 놓고 체크하지 않는 한 발견해 내기도 힘들다. 또, 시스템에 따라 발생하는 시기 또한 달라질 수 있어 여간 짜증나는 오류가 아닐 수 없다. 릴리즈 단계까지 발견되지 않는 경우도 있고, 심지어 모 회사 입사시험에도 나왔었다. 메모리 누수가 일어나는 것을 효과적으로 잡아 낼 방법은? 하고 말이다.

메모리 오류의 유형은 1.메모리 누수, 2.할당 오류, 3.dangling 포인터, 4.배열 경계 위반 등이 있는데, 이는 객체지향 언어에서도 크게 다르지 않다.
Article에서는 오류 각각의 케이스 별 예제코드와 그 대처법에 대해서 다루고 있다. 여기서 설명하고 있는 것들로 메모리 오류를 모두 방지할 수는 없다. 하지만, 메모리 오류의 각 케이스를 알고, 그에 대한 일반적인 대처방안, 메모리 도구 등 메모리 프로그래밍의 전략을 익히는 데는 꽤 괜찮은 기사가 아닐까 싶다.

기사 내용에도 언급이 되어 있지만, 대부분의 프로그램 오류는 잘못된 코딩 습관에서 비롯된다(그것은 협업에서도 마찬가지이다). 리뷰라고 할 것 까지도 없지만, 나는 주로 학생 개발자들의 수준에 맞추어 Article을 선택한다. 습관이라는 것은 그게 무엇이든 한 번 굳어지면 고치기 힘들다. 현업에서 개발을 꿈꾸는 많은 학생 개발자들이 올바른 코딩 습관을 기르는 데 조금이나마 도움이 되었으면 좋겠다.

메모리 디버깅 기법(바로가기)

닷넷 프레임워크 버전 변경을 했다가, 한참 고생했다.

'/xxxxx' 응용 프로그램에 서버 오류가 있습니다.

IIS 메타베이스에 액세스하지 못했습니다.

설명: 현재 웹 요청을 실행하는 동안 처리되지 않은 예외가 발생했습니다. 스택 추적을 검토하여 발생한 오류 및 코드에서 오류가 발생한 위치에 대한 자세한 정보를 확인하십시오.

예외 정보: System.Web.Hosting.HostingEnvironmentException: IIS 메타베이스에 액세스하지 못했습니다.

ASP.NET을 실행하는 데 사용되는 프로세스 계정에는 IIS 메타베이스(예: IIS://servername/W3SVC)에 대한 읽기 권한이 있어야 합니다. 메타베이스 권한을 수정하는 데 대한 자세한 내용은 http://support.microsoft.com/?kbid=267904를 참조하십시오.

소스 오류:

현재 웹 요청을 실행하는 동안 처리되지 않은 예외가 생성되었습니다. 아래의 예외 스택 추적을 사용하여 예외의 원인 및 위치 정보를 확인할 수 있습니다.

스택 추적:

[HostingEnvironmentException: IIS 메타베이스에 액세스하지 못했습니다.]
   System.Web.Configuration.MetabaseServerConfig.MapPathCaching(String siteID, VirtualPath path) +3492202
   System.Web.Configuration.MetabaseServerConfig.System.Web.Configuration.IConfigMapPath.MapPath(String siteID, VirtualPath vpath) +9
   System.Web.Hosting.HostingEnvironment.MapPathActual(VirtualPath virtualPath, Boolean permitNull) +163
   System.Web.CachedPathData.GetConfigPathData(String configPath) +382
   System.Web.CachedPathData.GetConfigPathData(String configPath) +243
   System.Web.CachedPathData.GetApplicationPathData() +68
   System.Web.CachedPathData.GetVirtualPathData(VirtualPath virtualPath, Boolean permitPathsOutsideApp) +3385711
   System.Web.Configuration.RuntimeConfig.GetLKGRuntimeConfig(VirtualPath path) +189


버전 정보: Microsoft .NET Framework 버전:2.0.50727.42; ASP.NET 버전:2.0.50727.42



해 결 방 법
aspnet_regiis.exe 도구를 사용하면 된다.
aspnet_regiis.exe 는 windows폴더에 microsoft.net 폴더 아래에 있고,
cmd에서 해당 경로를 찾아가서 아래와 같이 입력한다.
aspnet_regiis.exe -ga iwam_계정이름(컴퓨터이름)
예)C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe
그러면 iis메타베이스에 대한 접근 권한을 iwam 계정이 갖게 된다.
iwam계정은 iis 프로세스를 시작시키기 위한 식별자 계정.
그리고 나서 iis 를 열고 등록정보 중에 http 헤더부분을 보면 사용자지정 헤더부분에
X-Powered-By:APS.NET 이라고 있는지 확인 한 후,

없으면
다시 aspnet_regiis.exe를 열고
aspnet_regiis -i 
돌아가는지 확인
안되면
aspnet_regiis -e
aspnet_regiis -i
돌아가는지 확인

'프로그래밍' 카테고리의 다른 글

놀라운 Ajax solitaire 카드 놀이  (0) 2007.12.07
Ping 날리는 소스  (2) 2007.11.21
다음커뮤니케이션 R&D 팀장 IBM developerWorks Interview  (0) 2007.10.04
C# TIP 몇가지  (0) 2007.10.04
구글 가젯 만들기, Part1  (1) 2007.08.21