출처 : http://visu4l.tistory.com/343

 

가끔 가다가 잘 접속되던 서버가 아래와 같은 메세지를 띄우는 경우가 있다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
-생략-
Please contact your system administrator.
Add correct host key in /home/warren/.ssh/known_hosts to get rid of this message.
Offending key in /home/warren/.ssh/known_hosts:1
RSA host key for -생략(ip)- has changed and you have requested strict checking.
Host key verification failed.

참... 당황 스럽다...
욱긴건 다른 컴퓨터에서는 될때다...이러면 더 아리까리 해진다.

일단 해결법은 이렇다.

ssh-keygen -R [ IP or DomainName]


ex) ssh-keygen -R 110.110.110.110


그후에 다시 접속하면 이번엔 메시지가 바뀐다.
Are you sure you want to continue connecting (yes/no)?
대략 이런 메시지를 띄운다. 그럼 그냥 yes 하면 끝이다.


위에 상황을 예를 들면...
A host 가 있고 B server가 있다.
A는 항상 B 서버에 ssh접속하고 있었는데 B서버에 ssh나 os를 새로 설치 하는 작업을 했다.
그런후에 A는 똑같이 B에 접속을 한다. 이때 B에 IP는 똑같다면...
위와 같은 메시지가 뜬다!!

이렇게 되는 이유는 단순하다.
ssh 최초접속시에 A와 B에서 서로간에 인증 과정을 하는데.. B는 새로 설치되었으니 B는 상관없지만..
A는 예전B에 IP로 인증이 되어있는 상태에서 B로 로그인을 하면
로그인시에 예전에 IP로 인증했던 정보를 가지고 B로 로그인을 하려고 하지만 B는 인증정보가 없기때문에
위와 같은 현상이 나타난다.


만약 위에 명령어가 먹히지 않는다... 아직도 똑같다...
그러면 find / -name known_hosts 을 통해 해당파일을 찾아 지우면 된다.
보통 /root/.ssh/known_hosts 에 있다.
나니면 /home/username/.ssh/known_hosts

자신의 root면 root에 있는 것을 지워야 되고 일반 유저 이면 /home/username에 있는 걸 지워야겠죠?

'리눅스 서버에 대해서 > 리눅스 팁들' 카테고리의 다른 글

메모리 관리  (0) 2013.02.17
ptmalloc2 에 대한....  (0) 2013.02.17
[C언어] malloc, calloc, realloc를 이용한 유동 메모리 할당  (0) 2013.01.23
VIM 단축키  (0) 2013.01.21
vi 기본설정  (0) 2013.01.10
세그멘테이션 폴트는 수행 중인 프로그램이 메모리 상에 이상한 주소를 접근하려 할 때 발생한다. 여러분이 만든 프로그램이라면 세그멘테이션 폴트는 아마도 포인터가 뭔가 이상한 곳을 가리키고 있다는 말일 것이다. 그러나 표준 유닉스유틸리티인 경우 결국 같은 내용이겠지만 아마 프로그램에게 다룰 수 없는 이상한 입력을 준다든지 했을 것이다


프로그램을 중단시킬 수 있는 대부분의 버그들은 ‘SegmentationFault’라는 메시지를 남긴다. 이 메시지의 ‘fault’라는 말은 결함, 실수 등의 의미임을 쉽게 생각할 수 있다. 하지만 ‘segmentation’은 무슨 의미일까? 

세그먼테이션은 운영체제에서 메모리 관리(Memory Management)의 한 종류이다. 세그먼테이션을 정의한다면 완전히 머신(machine) 독립적인 주소 공간을 할당해주는 직접적인 방법이라고 할 수 있다. 

예를 들어, 컴파일러가 소스를 컴파일 할 때 다음과 같은 테이블을 만들 수 있다. 

  • 텍스트 소스를 저장하는 공간(테이블)
  • 변수의 특성, 이름 등을 저장하는 심벌 공간
  • 정수, 부동소수 등으로 지정된 상수를 저장하는 공간
  • 프로그램을 문법적으로 분석한 Parse tree
  • 컴파일러가 사용한 프로시저 콜 스택
이러한 여러 가지의 테이블을 세그먼테이션 방법에서는 각각 세그먼트라는 독립된 주소 공간을 할당하게 된다. 앞의 그림은 세그먼트를 나타낸 것이다. 반면에 가상 주소(Virtual Memory-pa ging의 대표적인 방법)라는 방법에서는 일정한 크기의 주소 공간을 여러 영역으로 나눠(세그먼테이션과는 다르게 일차원적이다) 앞의 여러 가지 테이블을 저장하게 된다. 

세그먼테이션을 사용할 때의 장점에는 여러 가지가 있지만 우선 각 프로시저가 주소 번지 0에서 시작되는 분리된 세그먼트를 갖기 때문에 독립된 프로시저의 연결이 단순해진다. 또한 여러 개의 프로세스가 프로시저나 데이터를 쉽게 공유할 수 있다. 이러 장점은 세그먼테이션이 가상 메모리와는 달리 그 크기가 유동적이라는 데서 기인한다.





Bus error 

이것은 성격상 세그먼테이션 폴트와 유사하다. 그러나 미묘한 차이가 있는데 버스에러란 커널이 스스로 문제점을 발견하지 못했다는 점에서다. 어떤 문제가 있음을 메모리 시스템(즉 하드웨어)이 발견한다. 많은 시스템에서느 이 메시지는 입출력 연산을 잘못 시도했음을 말한다. (있지도 않은 장치를 접근하려 했거나 뭔가 자연적이지 못했을때 등등)





- skt_wipi_c를 컴파일 할때 오류가 난 부분인데 wipi_sdk 버전을 낮추니 문제가 해결되었다. 상위 버전으로 컴파일 할때 다시 오류가 날지 모르겠다...


출처 : Tong - dicastyle님의 Compiler통

대부분의 개발자들은 버그를 없애기 위해 많은 시간과 노력을 들인다. 그럼에도 막상 소프트웨어를 출시하고 나면 미처 발견하지 못한 버그로 낭패를 당하기 십상이다. 시간과 비용의 재투자는 말할 것도 없다. 이 같은 이유에서 개발자라면 누구나 자신이 작성한 프로그램의 버그를 찾아주는 툴이 있었으면 하는 바람을 가진다.

Sparrow는 C/C++ 프로그램의 소스를 분석하고 치명적인 오류를 찾아주는 툴이다. 테스트 케이스 실행을 통해 오류를 찾는 기존 테스팅 방법과 달리 프로그램 실행 없이 소스 코드만 분석하여 자동으로 프로그램의 오류를 찾아준다. 시간과 비용을 줄이는 완전히 다른 형태인 것이다.

■ 소스 코드에서 오류 검색
Sparrow는 C/C++에서 흔히 발생하는 메모리 관련 오류를 찾아낸다. 메모리 관련 오류로는 버퍼 오버런(buffer overruns), 메모리 누수(memory leaks), 메모리 해제 후 사용(memory uses after free) 등이다. 이번 리뷰는 프로그램 소스를 쉽게 구할 수 있는 공개 소프트웨어 분석으로 진행했다. 테스트 환경은 펜티엄4 3.2GHz와 4GB 메모리가 설치된 PC와 리눅스 운영체제를 사용하였다.

사용 방법은 간단하다. Makefile이 있는 디렉토리에서 간단한 명령어를 입력하면 분석을 시작하고, 결과까지 알려준다. 먼저 smake라는 명령어를 실행해 소스 트리의 구조를 파악하고 실행 파일이나 라이브러리를 만드는데 필요한 파일을 정리한다.

C/C++ 환경의 메모리 오류 검색 smke 이후 생성된 분석 단위

그리고 분석하고 싶은 실행 파일이나 라이브러리를 선택하여 분석을 하면 된다. 분석 결과는 HTML 페이지로 만들어지므로 웹 브라우저에서 확인이 가능하다. 우선 tar를 분석하는 데 걸리는 시간을 측정하였더니 100초 정도가 소요되었다. tar의 소스 크기가 28,000라인 정도 되니까 분석 속도는 매우 빠른 편이다.

Sparrow는 tar에서 총 26개의 메모리 누수와 버퍼 오버런이 발생할 수 있다고 분석했다. 대부분의 소스 코드 분석기 툴이 그렇듯이, 여기서 알려주는 오류는 진짜 오류가 아닐 수 있다. 따라서 오류의 진위여부를 확인할 필요가 있다.

■ 스코어 기능, 분석 결과 진위 여부 확인
Sparrow는 분석 결과로 알려준 오류가 진짜 오류인지 거짓 오류인지를 사용자가 쉽게 판단 할 수 있도록 두 가지 기능을 제공한다. 하나는 분석기에서 나온 오류의 형태를 보고 통계적인 방법을 사용해 오류의 여부를 점수로 매기는 스코어 기능이다. 사용자는 오류에서 스코어가 높은 순서대로 하나씩 확인하여 걸러내면 된다.

이는 Sparrow만의 독특한 기능이라고 하겠다. 다른 한 가지는 프로그램이 실행되고 어떤 과정에서 오류가 발생하는 지를 확인할 수 있도록 오류의 근원에서 발생 시점까지 흐름을 추적해준다. 해제 후 사용 오류와 메모리 누수 오류의 경우에는 함수 호출과 리턴 등의 프로그램 실행 흐름의 큰 변화가 일어나는 지점에 한해 정보를 제공한다.

tar 분석 결과 중 일부 버퍼 오버런 경고 화면

버퍼 오버런의 경우는 실행 흐름의 정보가 매우 자세하다. 예를 들어, 버퍼 buf가 buf[x]라는 식을 통해 접근이 되었다면, buf와 x의 값에 영향을 주는 명령어만 링크로 연결하여 보여준다. 이러한 연결 고리를 Sparrow에서는 reason chain이라고 한다. 사용자는 오류 확인을 위해 꼭 필요한 명령문만 확인하면 된다는 얘기다.

실제로 tar 분석으로 나온 버퍼 오버런이 진짜인지 reason chain으로 쉽게 확인할 수 있었다. 부가적으로는 매크로, 변수, 함수를 정의한 지점을 찾는 기본적인 기능과 정의된 함수가 어느 지점에서 호출되었는지 함수 포인터를 통해 호출한 곳까지 찾아 알려준다.

■ 프로그램 버그 해결 도우미
Sparrow는 단순히 오류가 발생한 위치만 알려주는 툴이 아니다. 그 오류가 발생한 실행 흐름 중에서 꼭 체크해야 하는 부분을 알려주므로 라인 하나하나를 일일이 살펴볼 필요가 없다. 작업 속도가 생명인 테스트 과정에서 더없이 중요한 사항이다. 참고로 큰 규모의 프로그램 분석 성능은
www.spa-arrow.com에서 확인할 수 있다.

메모리 누수 경고 화면 메모리 누수가 발생한 지점 화면

최근 들어 소프트웨어 오류에 대한 관심과 우려가 집중되고 있다. 프로그램 덩치가 거대하고 복잡해지면서 오류의 원인도 점점 찾기가 힘들어질뿐더러 숨겨진 오류가 언제 나타날지 모르기 때문이다. 더군다나 디지털화가 가속되면서 곳곳에 쓰이는 소프트웨어의 오류는 일상생활과 밀접하게 연관될 수밖에 없다. 그래서 버그 해결의 중요성은 누차 강조해도 모자람이 없다.

Sparrow는 사용자가 분석 결과를 쉽게 확인할 수 있게끔 편의성 높은 UI와 기능을 제공한다. 누구나 사용할 수 있음을 의미한다. 오랜 기간 동안 사용되고 검증된 공개 프로그램을 분석한 탓에 리뷰 과정에선 버퍼 오버런 오류가 거의 없었다. 반면 메모리 누수 오류는 꽤 많이 발견되었다. 프로그램 버그로 인한 고민을 한다면 Sparrow가 그 대안이 될 수 있겠다.

 
전민식 월간 마이크로소프트웨어 필자 msjin@gmail.com | 2007-05-07 13:01


더 보기 http://www.ebuzz.co.kr/content/buzz_view.html?ps_ccid=21988#ixzz0sg5q9E5I


위와 같은 메시지가 뜰때
윈도우 -> 실행 창에

regsvr32 /u c:\windows\system32\comdlg32.ocx

와 같은 명령어를 치면 실행이 됩니다. orz

+ Recent posts