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

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

CentOS 기준

1. # vi /etc/resolv.conf

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

nameserver 58.277.183.227

nameserver 221.143.20.131

윈도우의 시간도 자유롭게 바꿀수 있는것처럼 리눅스도 가능합니다.

가끔 테스트를 위해서 (특히 다음 날로 넘어가는 AM 12:00 테스트를 위해서) 시간을 강제로 바꿔줘야 할 필요성을 느끼는데요.

우분투에서 시간을 수동으로 설정하는 방법은 아래와 같습니다.

1. 우분투 시간 수동 설정

# date -s "2018-05-17 17:59:48"

위는 2018년 5월 17일 17:59:48초로 시간을 강제로 바꾸고 싶을때의 예시죠.

현재 기준으로 이전 시간이든 이후 시간이든 상관없이 적용됩니다.

그런데 저렇게 해서 적용을 해도 실제 적용이 안되는 경우가 있습니다.

위와 같이 date 명령어를 이용해 수동으로 설정한뒤에 확인을 위해 바로 date 명령어 바로 쳐도 다시 실제시간으로 바뀌어버리는 케이스가 있는데요.

우분투 시간 동기화가 설정되어 있으니 그걸 해제하시면 됩니다.

2. 우분투 시간 동기화 해제 방법

# timedatectl set-ntp 0

그럼 시간 동기화가 해제 되서 다시 date 명령어를 통해 수동으로 시간 설정하면 잘 적용이 됩니다.

그 이후 다시 원래대로 실제 시간으로 셋팅하고 싶으면...

3. 우분투 시간 동기화 설정 방법

# timedatectl set-ntp 1

을 통해 바로 해결 가능합니다.

"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 오류가 발생하지 않을 것이다.