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

가끔 테스트를 위해서 (특히 다음 날로 넘어가는 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

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

준비물 : Apache-log4cxx / APR / APR-util

Apache-log4cxx Download : https://logging.apache.org/log4cxx/latest_stable/download.html

APR & APR-util Download : http://apr.apache.org/download.cgi

가장 먼저 저 세개의 파일을 다운 받아야 한다. 모두 tar.gz 형태로 압축되어 있어 압축 풀기가 그나마 수월한 편이다.

  APR 설치 방법

APR을 가장 먼저 기술하는 이유는 설치파일들의 의존성 때문이다.

우분투나 센트OS 쓸때는 겪어본적이 없는것 같았는데 이 의존성 때문에 은근히 사람 골때리게 만들더라...

의존성은 간단히 말해서 설치하기 위해서 먼저 깔려 있어야 하는 파일 뭐 그런거다

이 의존성 때문에 설치 순서는 무조건 APR -> APR-util -> log4cxx 로 가야 한다.

이 순서를 지키지 않는다면 make가 전혀 되지 않으니 주의. 물론 무시하고 설치하는 방법이 있다만 별로 권장하고 싶지는 않다.

APR을 설치하는 방법은 간단하다.

1) 다운로드 사이트에서  "Unix Source: apr-1.6.3.tar.gz"  다운받기(버전 상관없음. 그냥 최신버전으로...)

2) "gzip -dc apr-1.6.3.tar.gz | tar xvf -" 명령어를 통해 압축 풀기 (gzip이 없다면 rpm을 구해서 설치할것)

3) cd apr-1.6.3.tar.gz 로 폴더 이동

4) ./configure

5) make

6) make install

APR은 설치가 그리 어렵지 않다. 의외로 상당히 간단한 편

  APR-util 설치 방법

APR을 설치 했기 때문에 이제 APR-util 설치가 가능하다. 

APR-util을 설치하는 방법은 다음과 같다

1) 사이트에서 다운 받기

2) "gzip -dc apr-util-1.6.1.tar.gz | tar xvf -" 으로 압축 풀기

3) cd apr-util-1.6.1.tar.gz 폴더 이동

4) ./configure --with-apr='apr이 위치한 경로'    (예를 들어 아까 APR을 압축풀고 MAKE 하고 지지고 볶고 하던 곳이 /usr/local/apr-1.6.3 이라는 경로에 있다면 ./configure --with-apr='/usr/local/apr-1.6.3' 입력해야 함)

5) make

6) make install

=> APR-util 에서는 configure 에 옵션이 들어가기 시작했다. 이것은 어찌보면 당연한것인데 apr-util은 apr이 필수로 필요하기 때문에 어느 경로에 있는지 정확하게 찍어줘야 한다.

그렇기에 저런 옵션이 들어간것이다.

  Apahce-log4cxx 설치 방법

이제 APR과 APR-util 모두 설치했으므로 의존성에 의한 설치 불가는 발생하지 않는다.

1) 사이트에서 다운

2) 똑같이 압축풀기

3) 폴더 이동

4) ./configure --with-apr='apr이 위치한 경로' -- with-apr-util='apr-util이 위치한 경로'

   ex) ./configure --with-apr='/usr/local/apr-1.6.3' -- with-apr-util='/usr/local/apr-util-1.6.1'

5) make

6) make install

이렇게 하면 log4cxx 설치는 모두 끝이 난다. RPM이 없어서 소스 설치 하는게 매번 번거롭지만 어쨌든 AIX에서도 LOG4CXX를 사용할수 있음에 의의를 두자

  Error 발생시 해결방법

아마 Apache-log4cxx 설치 하다가 오류가 발생할 가능성이 좀 있다.

내가 겪은게 2가지 인데 하나는 No Space~ 로 시작한 오류와 하나는 ' ' not been declared 라는 오류이다.

No Space ~ 오류는 공간이 없는거니까 걍 해당 디스크의 용량을 확보해주자.

다만 not been declared가 조금 까다로운데 이럴 경우 소스 코드도 수정을 해야 한다.

예를 들어 

console.cpp : ::memcpy has not been declared 라는 에러가 발생할 가능성이 있다.

이럴 경우에는 해당 소스코드에 들어가서 헤더를 추가해주면 된다. 대체로 memcpy, memmove와 같은 것들이 걸리는데 대부분 String 관련 함수이니 

#include <cstring>을 소스코드 내에 추가하면 완성.

위의 케이스는 console.cpp를 vi 편집기로 들어가서 직접 헤더 하나 추가해주면 된다.

"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 기준으로 작성하였습니다. 그 외의 버전에서는 해결을 보증하지 않습니다.

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

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