Centos 7 환경에서 Qt Creator로 Qt 프로그래밍 중 몇 번 겪어보던 에러가 발생했다.

<GL/gl.h> no such file or directory... 어차피 원인은 저 gl.h 파일이 없다는 거니까 저걸 설치하기만 하면 끝이다.

원래 gl.h 위치는 /usr/include/GL에 있으며 아마 거기서 확인을 해봐도 비스무리한 파일은 보이는데 정작 gl.h가 없을 것이다. OpenGL 관련 파일이라는데 OpenGL을 심도적으로 파고들 것은 아니기 때문에 이 문제는 패스하고...

결론부터 말하자면 yum을 통해 매우 손쉽게 설치가 가능하다. 명령어는 아래와 같다.

yum install mesa-libGLU-devel

이 명령어만 치면 CentOS 환경에서는 알아서 gl.h 설치가 되고 컴파일 하는데는 문제가 없다.

한번 설치하고 나면 더이상 이런 문제가 발생하지 않으니 걱정은 안해도 된다.

출처 : http://wanochoi.com/?p=259

보통 이 오류가 뜨는 경우는 yum 을 사용한다거나 rdate를 사용할때 발생하는 경우에 많이 발생합니다.

이런 오류가 뜨면 rdate를 통해 시간 동기화도 참 힘들어지는데 찾아보니 nameserver를 찾을 수 없어서 생기는 문제라고 하네요.

CentOS 기준

1. # vi /etc/resolv.conf

2.  열린 resolv.conf 파일에 아래 두줄 추가 후 저장

nameserver 58.277.183.227

nameserver 221.143.20.131

예전에 내가 겪어본 OS 중 가장 호환성이 최악이었던 IBM AIX 7.2에서 log4cxx를 겨우 어찌해서 억지로 설치를 해서 사용중인데, 다시 우분투를 설치 할일이 있어서 설치를 했다.

그리고 당연히 쓰여야할 log4cxx를 설치하려고 했는데 리눅스도 만만치 않게 설치방법이 매우 드럽더라....

apr 까지야 어떻게 꾸역꾸역 했는데 apr-util-1.6.3을 설치할때 <expat.h> 그런 파일이나 디렉터리가 없습니다. 라는 에러 메세지를 띄우더라.

당연히 뭔가 설치를 해야겠거니 해서 찾았는데 CentOS 기준으로

'yum install expat-devel' 을 입력하면 expat가 설치된다고 한다.

옳거니! 그래서 우분투도 똑같이 'apt-get install expat-devel' 을 입력하고 패키지 설치를 기다렸더니

설치가 되지 않는다

패키지 이름이 틀렸겠거니 해서 찾아봤는데 의외로 우분투 패키지 설치 명령어가 없어서 기록 겸 남겨 본다.

우분투와 같은 데비안 계열의 리눅스에서 expat-devel을 설치하려면

'apt-get install libexpat1-dev' 을 입력 하면 된다.

정리하면 다음과 같다.

이상 끝!

"TNS-01189: The listener could not authenticate the user" error message

오라클 설치를 끝내고 이제 리스너 시작을 하기 위해 lsnrctl 명령어를 이용했건만, 위와 같은 오류가 하염없이 뜨면서 사람을 괴롭히는 경우가 있습니다.

이 오류를 해결하기 위해 구글링을 했는데 의외로 해결책이 마땅한게 없어서 애를 좀 먹었습니다. 

이 오류를 해결하기 위해서는 반드시 살펴봐야 하는 사항이 2가지 입니다.

1. 현재 리눅스 접속 아이디가 오라클을 사용할수 있는 아이디로 접속을 하였는가?

2. lsnrctl 버전이 오라클과 다르지는 않은가?

첫번째의 경우가 해결책이 되는 경우는 사실상 거의 없습니다. 하지만 혹시나 현재 root로 접속하고 있는건 아닌지 한번 살펴보시기 바랍니다.

아마 대부분 오라클을 리눅스에 설치하기 위해 구글을 통해 정보를 찾아 그 설치과정을 그대로 따라했을 것입니다.

이렇게 되면 대부분 "oracle" 이라는 아이디를 만들었을것인데요. 아무리 root라 할지라도 리스너를 실행시킬수가 없습니다.

오라클 관련 권한은 전부 아이디가 oracle인 녀석에게 있기 때문입니다.

▲ 아이디가 oracle인지 root인지 반드시 확인 해볼것 

그렇다면 두번째를 살펴봐야 하는데요. 제가 두번째 케이스를 고려하고 다시 수정해서 해결을 했습니다.

리스너 버전을 확인하기 위해서는 단순하게 lsnrctl 명령어를 쳐보시면 확인할수 있습니다.

그럼 위와 같이 버전을 확인하실수가 있습니다. 지금은 11.2로 버전이 잘 업데이트가 되었지만 제가 TNS-01189 오류가 났었을때는 버전이 10.2였습니다.

오라클 버전은 11g 인데 리스너는 10.2였으니 버전이 서로 맞지가 않아 lsnrctl 명령어가 먹질 않았던 것입니다.

버전을 업데이트를 하면 거의 90%는 해결된다고 보실수 있는 문제입니다. 90%라고 하는 이유는 나머지 10%는 다른 이유가 복합적으로 작용해서 생긴 문제일수도 있기 때문입니다.

버전 업데이트 하는 방법은 listener.ora 파일에 들어가셔서 리스너 설정을 해주면 바로 해결될수 있는 문제인데요.

구글에 버전에 맞는 리스너 설정법을 검색하시면 쉽게 업데이트 가능합니다.

예를 들어 저 같은 경우 오라클 11g의 리스너 설정을 하고 싶기 때문에 "오라클 11g 리스너 설정" 이라고 검색하면 수많은 블로거 분들이 아주 잘 포스팅한 글들이 매우 많기 때문에 그것들을 그대로 복붙한다음 IP와 포트만 바꿔 주시면 됩니다.

간단한 예로 제가 설정한 리스너 내용을 밑에 올립니다.

이것은 오라클 11g 리스너 설정 내용이므로 다른 버전을 쓰신다면 다른 버전을 검색하시면 되겠습니다.

이것으로 포스팅 마치겠습니다. 

간혹 리눅스에서 SVN 커밋을 하려고 하면 충돌 문제가 발생합니다. 그 중에서도 Aborting commit : 'xxx.c' remains in conflict 라는 문제가 자주 발생하는데요.

이건 두 대 이상의 컴퓨터에서 한쪽에서 작업하고 커밋하고 또 다른 쪽에서 작업하고 커밋하고 하다보면 꼬이게 되고 SVN은 이를 머지(병합)을 하는 경우에 충돌이 발생하게 됩니다.

머지가 완벽하게 이루어지지 않으면 SVN은 코드에 자동으로 수정하기 전 코드를 수정 후 코드에 자동으로 구분지어 갖다 붙이거나 아니면 아예 새로운 파일을 만들어내게 되는데 이러한 이전 파일이 남아있게 되면 위와 같은 오류가 발생하게 됩니다. 따라서 이 파일들을 삭제하게 되면 해결 될 문제입니다.

ls 명령어를 칠 경우 못 볼수도 있으니 ll 명령어를 통해 자세히 폴더내 파일을 조사. 그럼 아래와 같이 .c.mine이나 .c.r1428과 같은 파일이 있는것을 확인하실수 있습니다.

이 파일들을 지우면 됩니다. rm 명령어를 사용

하지만 삭제를 했음에도 불구하고 아래와 같이 커밋을 했는데도 또 실패하는 경우가 생깁니다. 이는 커밋을 하려 했는데 현재 파일의 버전과 커밋할 파일의 버전이 너무 차이가 날때 발생하게 됩니다. 예를 들어 다른 한쪽 컴퓨터에서는 커밋과 업데이트를 꾸준히 실시해서 버전이 1430인데 또다른 컴퓨터에서 똑같은 파일을 대상으로 커밋을 실시하려니 그 해당파일은 1420일수가 있습니다. 이는 커밋과 업데이트를 자주 실시하지 않아 동기화가 제대로 이루어지지 않은 겁니다.

따라서 1420인 올드한 파일을 SVN UPDATE 명령어를 통해 1430까지 버전을 끌어올리면 해결됩니다. 아래와 같이 svn update를 치면 1439까지 버전이 업데이트 된것을 확인하실수 있습니다.

이제 아래와 같이 다시한번 커밋을 시도하면 이젠 커밋이 제대로 완료되서 버전이 1440으로 한단계 더 끌어올려졌구요. update 명령어를 통해 최신버전을 유지하면 끝이 납니다.

SVN에서는 항상 커밋과 업데이트가 중요하니 자주 실시하시기 바랍니다. 어차피 SVN은 그렇게 쓰라고 만들어놓은거니까요.

/etc/init.d/crond restart 

라고 입력하면 재시작 된다. 

CentOS 6.5 버전에서 확인된 사항입니다. Ubuntu와 같은 다른 리눅스에서는 보증하지 않습니다.

안녕하세요. 이번에는 리눅스 관련 오류 해결방법에 관해 다뤄볼까 합니다.

현업에서 일하든 대학교 프로젝트를 하든 SVN(Subversion)은 굉장히 많이 사용합니다. 상당히 유용하기도 하구요. 하지만 리눅스에서는 조금 다루기가 어려운데요.

svn: OPTIONS of 'https://xxx.xxx.x.xxx:xxxx/svn/trunk': SSL handshake failed: SSL error: Key usage violation in certificate has been detected. (https://xxx.xxx.x.xxx:xxxx) 라는 오류가 뜨는 경우가 있습니다.

관련 자료 찾아봤더니 정보도 많이 없고 대부분 영어라서 해석하면서 보려니 머리가 아프더라구요. 결국 방법은 찾았습니다.

방법은 두가지 입니다.

1. SVN 서버에 들어가 '개인 인증서' 하나를 추가로 신설해 클라이언트에서 접속이 가능하게 한다

2. SVN 클라이언트 버전을 1.6.11 이상으로 업데이트 한다.

1번의 경우 가장 확실하고 클라이언트 버전을 그대로 유지할수 있다는 장점이 있지만 서버 컴퓨터에서 직접 조작을 해야 하고, 그럴 일은 없겠지만 혹시나 잘못돼서 서버 자체가 문제가 생기면 복구 수준으로 끝나지 않을지도 모릅니다. 저 같은 경우도 1번을 먼저 시도하려고 했다가 서버 관리자가 서버는 왠만해서 건드리지 말라고 부탁을 하여 1번 방법은 포기하였습니다.

1번 방법을 포스팅한 블로거 분들이 몇 분 계시므로 방법을 찾으시기 바랍니다.

2번 같은 경우에는 기존의 SVN을 지우고 새로 SVN을 다시 깔아야 하는 귀찮음이 존재합니다. 하지만 굳이 서버에 접근하지 않아도 되고 클라이언트(로컬 PC) 수준에서 끝낼수 있기 때문에 훨씬 안전합니다.

따라서 저같은 경우는 2번을 했는데요.

CentOS 6에서 그냥 yum install subversion 이라 명령어를 입력해서 설치를 하게되면 자연스럽게 1.6.11 버전이 설치가 됩니다. CentOS 7에서는 시도하지 않아서 어떤 버전이 깔릴지는 알수가 없습니다.

이러한 오류가 발생하는 이유는 인증서 방식이 서로 다르기 때문입니다.

윈도우는 대체로 OpenSSL을 사용하기 때문에 별 문제가 없으니 리눅스의 경우 SVN이 1.6.11 이하 버전이면 OpenSSL이 아니라 GnuTLS 방식을 사용하게 됩니다. 서로 호환이 되지 않아 발생하는 문제이기 때문에 대충 통과시켜 주거나 아니면 인증서 방식을 호환시키는 방법으로 해결해야 하죠.

다행히도 1.6.15 버전 이상부터는 리눅스 SVN도 OpenSSL을 지원하기 때문에 이러한 문제는 더이상 발생하지 않습니다. 극도의 호환성을 맞추기 위해서(예를 들어 고객사 서버와 환경을 동일하게 맞춰야 한다던가) 하는 경우가 아니라면 왠만해서 SVN을 최신버전으로 유지시켜주시기 바랍니다.

다만 리눅스에서 1.6.11 이상 버전을 설치하기 위해서는 단순한 명령어 한줄로 끝나지 않고 따로 외부에 접속을 해서 파일을 받아온다음 일일이 설치해줘야 하는 불편함이 따르니 그에 관련된 자료를 검색하셔서 적용하시기 바랍니다.

대체로 '리눅스 SVN 1.7' 이라던가 '리눅스 SVN 1.8' 과 같이 검색을 하면 친절하고 다양한 정보들이 많습니다.

리눅스 SVN과 관련해서 저런 오류가 뜬다면 버전이 안맞는 경우가 거의 100% 이니 이 방법을 적용해보시기 바랍니다.

이것으로 포스팅 마치겠습니다.

CentOS 7으로 넘어오면서 상당히 많은 부분이 바뀌었다.

그래서 대체적으로 구글로 검색해서 나오는 "yum install mysql-server" 명령어로는 설치가 불가능하다.

CentOS 7부터는 MySQL대신 MariaDB를 지원하기 때문이다.

하지만 회사에서 MySQL을 사용하거나 대학교 교수님이 굳이 MySQL을 고집한다던가 하는 이유로 무조건 MySQL을 써야한다면 아래의 명령어를 순서대로 입력하면 된다.

1. yum install http://dev.mysql.com/get/mysql-community-release-e17-5.noarch.rpm

2. yum install mysql-community-server

3. systemctl start mysqld

4. mysql

4번의 과정까지 마치면 

프롬프트가 mysql>로 바뀐다. 이렇게 되면 MySQL의 설치는 끝나게 된다.

나중에 라이브러리 파일이 없어서 문제가 생기면 

http://lwk24.tistory.com/63

글을 참고하면 된다.

CentOS 7 기준으로 작성하였습니다. 그 외의 버전에서는 해결을 보증하지 않습니다.

말 그대로 헤더파일이 없기 때문이다.

이 말은 mysql 라이브러리가 없기 때문이다.

정말로 없는지 확인하기 위해서는 다음과 같은 명령어를 입력해본다.

find / -name mysql.h

라고 검색했을때 아무것도 뜨지 않는다면 라이브러리가 없어 생기는 문제이므로 설치만 하면 바로 해결되는 아주 간단한 문제이다.

yum install mysql-devel

을 입력하면 일련의 설치과정이 진행되고 모든 설치가 끝난다음 

다시 find / -name mysql.h를 검색하면 이번에는 /usr/include/mysql/mysql.h 라는 결과가 출력된다.

이것으로 더이상 컴파일시 mysql.h : No such file or directory 오류가 발생하지 않을 것이다.